Export limit exceeded: 376678 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (376678 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-46492 | 1 Commenthol | 1 Md-fileserver | 2026-08-12 | 7.2 High |
| md-fileserver allows for local viewing of markdown files in a browser. Prior to version 1.10.3, a cross-site scripting (XSS) vulnerability exists in the application’s Markdown rendering logic. When user-supplied Markdown content is rendered, embedded raw HTML—including <script> tags—is processed and injected into the resulting page without sanitization, allowing arbitrary JavaScript execution in the context of the affected domain. This issue has been patched in version 1.10.3. | ||||
| CVE-2026-68432 | 1 Linux | 1 Linux Kernel | 2026-08-12 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series. Found by 0sec automated security-research tooling (https://0sec.ai). | ||||
| CVE-2026-68438 | 1 Linux | 1 Linux Kernel | 2026-08-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: smp: Make CSD lock acquisition atomic for debug mode Commit b0473dcd4b1d ("smp: Improve smp_call_function_single() CSD-lock diagnostics") changed smp_call_function_single() so that, when CSD lock debugging is enabled, async !wait calls use the destination CPU csd_data. That improves diagnostics, but it also removes the single-writer property that made the old csd_lock() safe: multiple CPUs can now prepare the same destination CPU CSD concurrently. csd_lock() currently waits for CSD_FLAG_LOCK to clear and then sets the bit with a non-atomic read-modify-write. Two senders can both see an unlocked CSD, set the bit, overwrite the callback fields, and enqueue the same llist node. Re-adding a node that is already the queue head can make node->next point to itself, leaving the target CPU stuck walking call_single_queue. Later synchronous work, such as a TLB shootdown, can then remain queued and trigger soft-lockup warnings or panics. Keep the single csd_lock() implementation, but when CSD lock debugging is enabled, acquire CSD_FLAG_LOCK with try_cmpxchg_acquire(). This makes the destination CPU CSD a real atomic lock in the only configuration where it can be shared by multiple remote senders, while preserving the existing non-debug fast path. | ||||
| CVE-2026-68439 | 1 Linux | 1 Linux Kernel | 2026-08-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it. | ||||
| CVE-2026-68440 | 1 Linux | 1 Linux Kernel | 2026-08-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead. | ||||
| CVE-2026-68441 | 1 Linux | 1 Linux Kernel | 2026-08-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d ("bpf: add bpf_redirect() helper"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs. Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working. The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before. | ||||
| CVE-2026-68444 | 1 Linux | 1 Linux Kernel | 2026-08-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input. | ||||
| CVE-2026-68445 | 1 Linux | 1 Linux Kernel | 2026-08-12 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects. | ||||
| CVE-2026-34196 | 3 Google, Imaginationtech, Linux | 4 Android, Ddk, Graphics Ddk and 1 more | 2026-08-12 | 7.8 High |
| Software installed and run as a non-privileged user may conduct improper GPU system calls to cause an integer overflow and map two GPU virtual addresses to the same physical address. One of these virutal mappings can be freed along with the physical page, allowing for a read/write UAF via the second mapping The second virtual mapping references a physical address that has been freed after the first virtual mapping has been freed. This allows the physical memory to be allocated (for example) by another process and read/written to. | ||||
| CVE-2026-41154 | 3 Google, Imaginationtech, Linux | 4 Android, Ddk, Graphics Ddk and 1 more | 2026-08-12 | 7.8 High |
| Software installed and run as a non-privileged user may cause OOB kernel memory reads or writes through GPU API calls. When indexing pages larger than 4kB in the page freeing logic of the sparse memory implementation, incorrect buffer indexing leads to OOB access. | ||||
| CVE-2026-45196 | 3 Google, Imaginationtech, Linux | 4 Android, Ddk, Graphics Ddk and 1 more | 2026-08-12 | 7.8 High |
| Kernel software installed and running inside a Host VM may post improper commands to the GPU Firmware to trigger a GPU register access which can lead to privilege escalation. | ||||
| CVE-2026-16907 | 1 Ibm | 1 I | 2026-08-12 | 7.6 High |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to execute arbitrary code due to improper bounds checking. | ||||
| CVE-2026-17271 | 1 Ibm | 1 I | 2026-08-12 | 7.5 High |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote attacker to cause a denial of service due to improper validation of input size. | ||||
| CVE-2026-45203 | 3 Google, Imaginationtech, Linux | 4 Android, Ddk, Graphics Ddk and 1 more | 2026-08-12 | 7.8 High |
| Kernel software installed and running inside a Host VM may post improper commands to the GPU Firmware to trigger a memory write outside the permitted range of memory for the host kernel. A TOCTOU bug existed where a malicious driver could modify values in memory after firmware validation but before use. | ||||
| CVE-2026-59138 | 1 Microsoft | 20 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 17 more | 2026-08-12 | 6.5 Medium |
| Null pointer dereference in Microsoft Remote Registry Service allows an authorized attacker to deny service over a network. | ||||
| CVE-2026-54984 | 1 Microsoft | 20 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 17 more | 2026-08-12 | 7.8 High |
| Heap-based buffer overflow in Windows Imaging Component allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-19588 | 1 Samsung Open Source | 1 Rlottie | 2026-08-12 | 6.5 Medium |
| Integer Overflow to Buffer Overflow vulnerability in Samsung Open Source rlottie allows Overflow Buffers. | ||||
| CVE-2026-16856 | 1 Ibm | 1 I | 2026-08-12 | 8.8 High |
| IBM i 7.6, and 7.5 could allow a local attacker to gain elevated privileges due to improper neutralization of special elements used in an OS command. | ||||
| CVE-2026-61346 | 1 Microsoft | 16 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 13 more | 2026-08-12 | 7 High |
| Use after free in Windows Graphics Kernel allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-17110 | 1 Ibm | 1 I | 2026-08-12 | 8.8 High |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to execute arbitrary commands and obtain sensitive information due to improper privilege management. | ||||