Complete feed
Recently updated
Advisories the vendor has revised
Android app · Google Play
Take your CVE monitoring with you.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.
Medium [CVE-2026-64514] gate must_wait writability check on pte_present
In the Linux kernel, the following vulnerability has been resolved: userfaultfd: gate must_wait writability check on pte_present() userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result. The intent of the check is "is this fault still WP-blocked?". A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says "wait", and the thread stays asleep until a UFFDIO_WAKE that may never arrive. Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns "don't wait" and lets the fault path retry. This vulnerability occurs when the userfaultfd_must_wait() and userfaultfd_huge_must_wait() functions incorrectly read Page Table Entries (PTEs) without proper locking during memory operations.
Medium [CVE-2026-64299] Prevent out-of-bounds read in glob matching
In the Linux kernel, the following vulnerability has been resolved: tracing: Prevent out-of-bounds read in glob matching String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it. regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint. Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour. This vulnerability allows a local attacker to trigger an out-of-bounds read by providing specially crafted input to glob matching functions. The issue arises because these functions did not correctly handle string event fields that were not properly terminated.
Medium [CVE-2026-64367] validate report size to prevent stack buffer overflow
In the Linux kernel, the following vulnerability has been resolved: HID: hid-goodix-spi: validate report size to prevent stack buffer overflow goodix_hid_set_raw_report() builds a protocol frame in a 128-byte stack buffer (tmp_buf), writing an 11-12 byte header followed by the caller-supplied report data. The HID core caps report size at HID_MAX_BUFFER_SIZE (16384) by default, while the driver does not set hid_ll_driver.max_buffer_size and performs no bounds checking before copying the payload: memcpy(tmp_buf + tx_len, buf, len); A hidraw SET_REPORT ioctl with a report larger than ~116 bytes overflows the stack buffer. Add a size check after constructing the header, rejecting reports that would exceed the buffer capacity. Discovered by Atuin - Automated Vulnerability Discovery Engine. This vulnerability, a stack buffer overflow, allows a local attacker to provide an oversized report to the system. This can lead to a buffer overflow, potentially enabling the attacker to execute arbitrary code with elevated privileges or cause the system to crash, resulting in a denial of service. Red Hat severity: Moderate. Weakness: CWE-120. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.
Medium [CVE-2026-64324] validate free block extents against the partition length
In the Linux kernel, the following vulnerability has been resolved: udf: validate free block extents against the partition length udf_free_blocks() checks the logical block number and count against the partition length, but drops the extent offset from that final bound. A crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition, which later indexes past the space bitmap array. A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. This is a local availability issue. On desktop systems where UDisks/polkit allows the active user to mount removable UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply the crafted filesystem and trigger the panic by truncating a writable file on it. Systems that require root or CAP_SYS_ADMIN to mount the image have a higher prerequisite. No confidentiality or integrity impact is claimed: the reproduced primitive is an out-of-bounds read of a bitmap pointer slot followed by a kernel panic. Use the already computed logicalBlockNum + offset + count value for the partition length check. Also make load_block_bitmap() reject an out-of-range block group before indexing s_block_bitmap[], so corrupted callers cannot walk past the flexible array. A flaw was found in the Linux kernel's Universal Disk Format (UDF) filesystem.
Medium [CVE-2026-64297] check return value of module_extend_max_pages
In the Linux kernel, the following vulnerability has been resolved: module: decompress: check return value of module_extend_max_pages() module_extend_max_pages() calls kvrealloc() internally and returns -ENOMEM on allocation failure. If the initial allocation fails, info->pages remains NULL and info->max_pages remains 0. Subsequent calls to module_get_next_page() will attempt to dynamically grow the array by calling module_extend_max_pages(info, 0) since info->used_pages is 0. This results in kvrealloc(NULL, 0) returning ZERO_SIZE_PTR, which is treated as a success, leading to a dereference of ZERO_SIZE_PTR and a kernel oops. Fix: add the missing error check after module_extend_max_pages() and return immediately on failure. This matches the pattern used by every other kvrealloc() caller in the module loading path. [Sami: Corrected the analysis in the commit message.] An unchecked return value in the `module_extend_max_pages()` function within the module decompression logic can lead to a null pointer dereference. This vulnerability can be triggered if memory allocation fails during module loading, resulting in a kernel oops. This can allow a local attacker to cause a denial of service (DoS) by crashing the system. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-476. Affected Red Hat products: Red Hat Enterprise Linux 10.
Medium [CVE-2026-64365] fix UAF on inrange_timer at driver unbind
In the Linux kernel, the following vulnerability has been resolved: HID: letsketch: fix UAF on inrange_timer at driver unbind letsketch_driver does not provide a.remove callback, but letsketch_probe() arms a per-device timer: timer_setup(&data->inrange_timer, letsketch_inrange_timeout, 0); The timer is re-armed from letsketch_raw_event() with a 100 ms timeout on every pen-in-range report, and its callback dereferences data->input_tablet to deliver a synthetic BTN_TOOL_PEN release. letsketch_data is allocated with devm_kzalloc(), and its input_dev fields are devm-allocated via letsketch_setup_input_tablet(). On device unbind (USB unplug or rmmod), the HID core runs its default teardown and devm cleanup frees both letsketch_data and the input devices. Because no.remove callback exists, nothing drains the timer first: if raw_event armed it within ~100 ms of the unbind, the pending timer fires on freed memory. This is a UAF read of data and of data->input_tablet, followed by input_report_key() / input_sync() into the freed input_dev. The same problem can occur on the probe error path: if hid_hw_start() enabled I/O on an always-poll-quirk device and then failed, raw_event may have armed the timer before devm releases data. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-64292] Move vevent memory allocation outside spinlock
In the Linux kernel, the following vulnerability has been resolved: iommufd: Move vevent memory allocation outside spinlock The veventq memory allocation happens inside the spinlock. Given its depth is decided by the user space, this leaves a vulnerability, where userspace can allocate large queues to exhaust atomic memory reserves. Move the allocation outside the spinlock and use GFP_NOWAIT, which can fail fast under memory pressure without dipping into the GFP_ATOMIC reserves or direct-reclaiming from the threaded IRQ handler. On allocation failure, queue the lost_events_header (so userspace learns of the drop) and return -ENOMEM so the caller learns of the kernel-side memory pressure. This is intentionally distinct from the queue-overflow path, which also queues the lost_events_header but returns 0: a full queue is an expected userspace-pacing condition rather than a kernel error. A subsequent change will cap the upper bound of the veventq_depth. A local user can exploit this vulnerability by allocating large `veventq` queues, which are processed inside a spinlock. This can lead to the exhaustion of atomic memory reserves, resulting in a Denial of Service (DoS) condition. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-770. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9.
Medium [CVE-2026-64403] validate option length before reading conf opt value
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate option length before reading conf opt value l2cap_get_conf_opt() derives the option length from the attacker-controlled opt->len field and immediately dereferences opt->val (as u8, get_unaligned_le16() or get_unaligned_le32(), or a raw pointer for the default case) before any caller has confirmed that opt->len bytes are present in the buffer. The callers (l2cap_parse_conf_req(), l2cap_parse_conf_rsp() and l2cap_conf_rfc_get()) only detect a malformed option afterwards, once the running length has gone negative, by which point the out-of-bounds read has already executed. An existing post-hoc length check keeps the garbage value from being consumed, so this is not a data leak in the current control flow. It is still a validate-after-use ordering bug: up to 4 bytes are read past the end of the buffer before it is known to contain them, and it is fragile to future changes in the callers. Fix it at the source. Pass the end of the buffer into l2cap_get_conf_opt() and refuse to touch opt->val unless the full option (header + value) fits. Each caller computes an end pointer once before the loop and checks the return value directly instead of inferring the error from a negative length.
Medium [CVE-2026-64409] fix infinite loop in btmtksdio_txrx_work
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work() Every once in a while we see a hung btmtksdio_flush() task: INFO: task kworker/u17:0:189 blocked for more than 122 seconds. __cancel_work_timer+0x3f4/0x460 cancel_work_sync+0x1c/0x2c btmtksdio_flush+0x2c/0x40 hci_dev_open_sync+0x10c4/0x2190 [..] It all boils down to incorrect time_is_before_jiffies() usage in btmtksdio_txrx_work(). The btmtksdio_txrx_work() loop is expected to be terminated if running for longer than 5*HZ. However the timeout check is twisted: time_is_before_jiffies(old_jiffies + 5*HZ) evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a timeout has occurred. Using OR with time_is_before_jiffies(txrx_timeout) means that: - before the 5-second timeout: the condition is `int_status || false`, so it loops as long as there are pending interrupts. - after the 5-second timeout: the condition becomes `int_status || true`, which is always true. When the loop becomes infinite btmtksdio_txrx_work() loop never terminates and never releases the SDIO host. Fix loop termination condition to actually enforce a 5*HZ timeout. A flaw was found in the Linux kernel's Bluetooth MTK SDIO (btmtksdio) driver. An incorrect timeout check in the btmtksdio_txrx_work() function can lead to an infinite loop.
Medium [CVE-2026-64352] Allow LPM map access from sleepable BPF programs
In the Linux kernel, the following vulnerability has been resolved: bpf: Allow LPM map access from sleepable BPF programs trie_lookup_elem() annotates its rcu_dereference_check() walks with only rcu_read_lock_bh_held(). Because rcu_dereference_check(p, c) resolves to "c || rcu_read_lock_held()", this passes for XDP/NAPI and classic RCU readers but fails for sleepable BPF programs, which enter via __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace(). trie_update_elem() and trie_delete_elem() have the same problem in a different form: they walk the trie with plain rcu_dereference(), which asserts rcu_read_lock_held() unconditionally. Both are reachable from sleepable BPF programs via the bpf_map_update_elem / bpf_map_delete_elem helpers, and from the syscall path under classic rcu_read_lock(). In the writer paths the trie is actually protected by trie->lock (an rqspinlock taken across the walk); we never relied on the RCU read-side lock to keep nodes alive there. A sleepable LSM hook that ends up touching an LPM trie therefore triggers lockdep on debug kernels: ============================= WARNING: suspicious RCU usage 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage!
Medium [CVE-2026-64328] Fix DMA fence leak
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix DMA fence leak In ffs_dmabuf_transfer(), a ffs_dma_fence object is kmalloc'd, with the underlying dma_fence later initialized by dma_fence_init(), which sets its kref counter to 1. Then, dma_resv_add_fence() gets a second reference, and a pointer to the ffs_dma_fence is passed as the usb_request's "context" field. The dma-resv mechanism will manage the second reference, but the first reference is never properly released; the ffs_dmabuf_cleanup() function decreases the reference count, but only to balance with the reference grab in ffs_dmabuf_signal_done(). The code will then slowly leak memory as more ffs_dma_fence objects are created without being ever freed. Address this issue by transferring ownership of the fence to the DMA reservation object, by calling dma_fence_put() right after dma_resv_add_fence(). The ffs_dma_fence then gets properly discarded after being signalled. Specifically, a DMA (Direct Memory Access) fence leak exists in the `f_fs` module's `ffs_dmabuf_transfer()` function. This issue causes `ffs_dma_fence` objects to be allocated without their initial reference being properly released. Repeated exploitation of this flaw could lead to a gradual memory leak, potentially resulting in a denial of service due to system resource exhaustion.
Medium [CVE-2026-64322] validate sparing table length as an entry count, not a byte count
In the Linux kernel, the following vulnerability has been resolved: udf: validate sparing table length as an entry count, not a byte count udf_load_sparable_map() accepts a sparing table when sizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements: for (i = 0; i reallocationTableLen); i++) { struct sparingEntry *entry = &st->mapEntry[i];... entry->origLocation... } in udf_get_pblock_spar15() and udf_relocate_blocks(). A reallocationTableLen of N therefore passes the check whenever sizeof(*st) + N mapEntry[] is an out-of-bounds write. A flaw was found in the Linux kernel's Universal Disk Format (UDF) filesystem. This can lead to memory corruption, potentially resulting in a denial of service or arbitrary code execution. This issue is triggered by a specially crafted disk image containing on-disk metadata inconsistencies. Exploitation requires that an attacker convince a user to download and use a malicious image from an untrusted source, a scenario with limited practical impact. Red Hat rates this as Low severity. Weakness: CWE-125. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; and 2 more.
Medium [CVE-2026-64474] prevent infinite loop in vfio_mig_get_next_state on blocked arc
In the Linux kernel, the following vulnerability has been resolved: vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc vfio_mig_get_next_state() walks vfio_from_fsm_table[] one step at a time, looping to skip optional states the device does not support until *next_fsm is supported. A blocked transition is encoded as VFIO_DEVICE_STATE_ERROR, which the trailing return reports as -EINVAL. The skip loop does not account for the ERROR sentinel. state_flags_table[ERROR] is ~0U and vfio_from_fsm_table[ERROR][*] is ERROR, so once *next_fsm becomes ERROR the loop condition stays true and *next_fsm never changes. The blocked arcs STOP_COPY -> PRE_COPY and STOP_COPY -> PRE_COPY_P2P map to ERROR yet pass the support check on a precopy-capable device, causing the loop to spin forever while holding the driver state mutex. This can result in a soft lockup, and a panic with softlockup_panic set. A flaw was found in the Linux kernel's Virtual Function I/O (VFIO) device migration feature. The `vfio_mig_get_next_state()` function, responsible for managing device migration states, contains an infinite loop. This occurs when processing certain blocked transitions, causing the system to hold a driver state mutex indefinitely. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-835.
Medium [CVE-2026-64308] ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD)
ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD). Red Hat rates this moderate (CVSS 5.5). Weakness: CWE-909.
Medium [CVE-2026-64458] handle extreme intervals in damon_hot_score
handle extreme intervals in damon_hot_score(). Red Hat rates this moderate (CVSS 5.5). Weakness: CWE-369.
Medium [CVE-2026-64336] fix information leak
fix information leak. Red Hat rates this moderate (CVSS 5.5). Weakness: CWE-787.
Medium [CVE-2026-64282] Don't leak PFN when kvm_translate_vncr races MMU notifier
Don't leak PFN when kvm_translate_vncr() races MMU notifier. Red Hat rates this low (CVSS 5.5). Weakness: CWE-772.
Medium [CVE-2026-64284] Ensure vendor's exit handler runs before fastpath userspace exits
Ensure vendor's exit handler runs before fastpath userspace exits. Red Hat rates this moderate (CVSS 5.5). Weakness: CWE-367.
Medium [CVE-2026-64405] Fix null ptr deref in hci_abort_conn
Fix null ptr deref in hci_abort_conn(). Red Hat rates this moderate (CVSS 5.5). Weakness: CWE-476.
Medium [CVE-2026-64301] fix of_node refcount leak in scmi_regulator_probe
fix of_node refcount leak in scmi_regulator_probe(). Red Hat rates this low (CVSS 5.5).