Complete feed
No mitigation yet
No fix, workaround or mitigation extracted yet
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.
Advisory [CVE-2026-63819] fix to do sanity check on f2fs_get_node_folio_ra
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on f2fs_get_node_folio_ra() kernel BUG at fs/f2fs/file.c:845!
Advisory [CVE-2026-63815] bound i_inline_xattr_size for non-inline-xattr inodes
In the Linux kernel, the following vulnerability has been resolved: f2fs: bound i_inline_xattr_size for non-inline-xattr inodes When the flexible_inline_xattr feature is enabled, do_read_inode() loads the on-disk i_inline_xattr_size unconditionally: if (f2fs_sb_has_flexible_inline_xattr(sbi)) fi->i_inline_xattr_size = le16_to_cpu(ri->i_inline_xattr_size); but sanity_check_inode() only range-checks it when the inode also has the FI_INLINE_XATTR flag set. An inode that carries an inline dentry or inline data but not FI_INLINE_XATTR -- the normal layout for an inline directory -- therefore keeps a fully attacker-controlled i_inline_xattr_size from a crafted image. get_inline_xattr_addrs() returns that value with no flag gating, so it feeds the inode geometry: MAX_INLINE_DATA() = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1) NR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...) addrs_per_page() = CUR_ADDRS_PER_INODE - i_inline_xattr_size A large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY() negative, so make_dentry_ptr_inline() sets d->max (int) to a negative value. The inline directory walk then compares an unsigned long bit_pos against that negative d->max, which is promoted to a huge unsigned bound, and reads far past the inline area: while (bit_pos max)/* fs/f2fs/dir.c */... test_bit_le(bit_pos, d->bitmap) / d->dentry[bit_pos]...
Advisory [CVE-2026-63814] validate ACL entry sizes in f2fs_acl_from_disk
In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged.
Advisory [CVE-2026-63816] fix UAF issue on f2fs_inode_info.atomic_inode
In the Linux kernel, the following vulnerability has been resolved: f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode - ioctl(F2FS_IOC_GARBAGE_COLLECT_RANGE)- shrink - f2fs_gc - gc_data_segment - ra_data_block(cow_inode) - mapping = F2FS_I(inode)->atomic_inode->i_mapping: f2fs_is_cow_file(cow_inode) is true - f2fs_evict_inode(atomic_inode) - clear_inode_flag(fi->cow_inode, FI_COW_FILE) - F2FS_I(fi->cow_inode)->atomic_inode = NULL... - truncate_inode_pages_final(atomic_inode) - f2fs_grab_cache_folio(mapping): create folio in atomic_inode->mapping - clear_inode(atomic_inode) - BUG_ON(atomic_inode->i_data.nrpages) We need to add a reference on fi->atomic_inode before using its mapping field during garbage collection, otherwise, it will cause UAF issue. A flaw was found in the f2fs (Flash-Friendly File System) component of the Linux kernel. This use-after-free (UAF) vulnerability occurs during garbage collection operations when handling Copy-On-Write (COW) files. A local attacker could exploit this by triggering garbage collection, leading to a premature deallocation of memory. Subsequent access to this freed memory could result in a system crash, causing a Denial of Service (DoS), or potentially lead to privilege escalation. Red Hat severity: not rated. Weakness: CWE-825.
Advisory [CVE-2026-63839] Fix memory leak in lwmi_dev_evaluate_int
In the Linux kernel, the following vulnerability has been resolved: platform/x86: lenovo-wmi-helpers: Fix memory leak in lwmi_dev_evaluate_int() lwmi_dev_evaluate_int() leaks output.pointer when retval == NULL (found by sashiko.dev [1]). Fix it by moving `ret_obj = output.pointer' outside of the `if (retval)' block so that it is always freed by the __free cleanup callback. No functional change intended. The `lwmi_dev_evaluate_int()` function was identified to have a memory leak, where allocated memory was not properly released under certain conditions. This could lead to a gradual consumption of system memory, potentially impacting system stability or performance over extended periods. Red Hat severity: not rated. Weakness: CWE-772. 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.
Advisory [CVE-2026-64142] close durable scavenger races against m_fp_list lookups
In the Linux kernel, the following vulnerability has been resolved: ksmbd: close durable scavenger races against m_fp_list lookups ksmbd_durable_scavenger() has two related races against any walker that iterates f_ci->m_fp_list, including ksmbd_lookup_fd_inode() (used by ksmbd_vfs_rename) and the share-mode checks in fs/smb/server/smb_common.c. (1) fp->node list-head reuse. Durable-preserved handles can remain linked on f_ci->m_fp_list after session teardown so share-mode checks still see them while the handle is reconnectable. The scavenger collected expired handles by adding fp->node to a local scavenger_list after removing them from the global durable idr. Because fp->node is the same list_head used by m_fp_list, list_add(&fp->node, &scavenger_list) overwrites the m_fp_list links and corrupts both lists. CONFIG_DEBUG_LIST can report this on the share-mode walk path. (2) Refcount race against m_fp_list walkers. The scavenger qualifies an expired durable handle with atomic_read(&fp->refcount) > 1 and fp->conn under global_ft.lock, removes fp from global_ft, then drops global_ft.lock before unlinking fp from m_fp_list and freeing it.
Advisory [CVE-2026-64167] skip KHO for crash kernel
In the Linux kernel, the following vulnerability has been resolved: kho: skip KHO for crash kernel kho_fill_kimage() unconditionally populates the kimage with KHO metadata for every kexec image type. When the image is a crash kernel, this can be problematic as the crash kernel can run in a small reserved region and the KHO scratch areas can sit outside it. The crash kernel then faults during kho_memory_init() when it tries phys_to_virt() on the KHO FDT address: Unable to handle kernel paging request at virtual address xxxxxxxx... fdt_offset_ptr+... fdt_check_node_offset_+... fdt_first_property_offset+... fdt_get_property_namelen_+... fdt_getprop+... kho_memory_init+... mm_core_init+... start_kernel+... kho_locate_mem_hole() already skips KHO logic for KEXEC_TYPE_CRASH images, but kho_fill_kimage() was missing the same guard. As kho_fill_kimage() is the single point that populates image->kho.fdt and image->kho.scratch, fixing it here is sufficient for both arm64 and x86 as the FDT and boot_params path are bailing out when these fields are unset. A flaw was found in the Linux kernel's kexec_handover (KHO) mechanism. When a crash kernel attempts to initialize KHO memory, it can try to access memory outside its reserved region, leading to a kernel paging request fault. This can result in a system crash, causing a Denial of Service (DoS) for a local user.
Advisory [CVE-2026-64164] fix sleep while in atomic context in btrfs_sync_file
In the Linux kernel, the following vulnerability has been resolved: btrfs: tracepoints: fix sleep while in atomic context in btrfs_sync_file() The trace event btrfs_sync_file() is called in an atomic context (all trace events are) and its call to dput(), which is needed due to the call to dget_parent(), can sleep, triggering a kernel splat. This can be reproduced by enabling the trace event and running btrfs/056 from fstests for example.
Advisory [CVE-2026-64087] (pmbus/adm1266) reject implausible blackbox record_count
In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/adm1266) reject implausible blackbox record_count adm1266_nvmem_read_blackbox() loops over a record_count that comes straight from byte 3 of the BLACKBOX_INFO response. The destination buffer is data->dev_mem, sized for the nvmem cell's declared 2048 bytes (ADM1266_BLACKBOX_MAX_RECORDS * ADM1266_BLACKBOX_SIZE = 32 * 64). A device that reports a record_count greater than 32 -- whether due to firmware bugs, bus corruption, or a non-responsive slave returning 0xff -- would walk read_buff past the end of the dev_mem allocation on the trailing iterations. Cap record_count at ADM1266_BLACKBOX_MAX_RECORDS (introduced here) before entering the loop and return -EIO on any larger value, so a malformed BLACKBOX_INFO response cannot drive the loop out of bounds. A malformed response from a hardware monitoring device could cause the driver to read beyond the allocated memory buffer. This out-of-bounds read can lead to system instability or denial of service. Red Hat severity: not rated. Weakness: CWE-125. 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.
Advisory [CVE-2026-64083] (pmbus/adm1266) reject short block-read responses in the GPIO accessors
In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/adm1266) reject short block-read responses in the GPIO accessors adm1266_gpio_get() and adm1266_gpio_get_multiple() both compose the pin-status word as pins_status = read_buf[0] + (read_buf[1] << 8); right after i2c_smbus_read_block_data(), guarding only against an error return. A well-behaved device returns 2 bytes for GPIO_STATUS/PDIO_STATUS, but the helper happily reports a 0- or 1-byte response too. If the device returns 0 bytes, both read_buf slots are uninitialized stack memory; if it returns 1 byte, read_buf[1] is. The composed value then flows through set_bit() into the caller's *bits in adm1266_gpio_get_multiple(), or into the return value of adm1266_gpio_get(), and ends up in userspace via gpiolib (sysfs and the char-dev ioctls). That leaks a few bits of kernel stack per request on any device whose firmware glitch, bus error, or hostile slave produces a short block-read response. Add the missing length check to both call sites and surface a short response as -EIO. The adm1266_gpio_get() and adm1266_gpio_get_multiple() functions fail to validate the length of responses from I2C block-read operations. A local user or a malicious I2C (Inter-Integrated Circuit) slave device can exploit this by providing a short block-read response.
Advisory [CVE-2026-64154] Fix a reference leak in a6xx_gpu_init
In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Fix a reference leak in a6xx_gpu_init() In a6xx_gpu_init(), node is obtained via of_parse_phandle(). While there was a manual of_node_put() at the end of the common path, several early error returns would bypass this call, resulting in a reference leak. Fix this by using the __free(device_node) cleanup handler to release the reference when the variable goes out of scope. Patchwork: A flaw was found in the Linux kernel's Adreno graphics processing unit (GPU) driver. This vulnerability occurs in the `a6xx_gpu_init()` function, where a device node reference is not properly released under certain error conditions. This oversight can lead to a gradual accumulation of unreleased resources, potentially causing resource exhaustion over extended periods of operation. While not directly exploitable for arbitrary code execution, this resource management issue could impact system stability and availability. Red Hat severity: not rated. Weakness: CWE-911. 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.
Advisory [CVE-2026-64050] don't mix devm and drmm functions
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: don't mix devm and drmm functions Mixing devm and drmm functions will result in a use-after-free on msm driver teardown if userspace keeps a reference on the drm device: The WB connector data will be destroyed because of the use of devm_kzalloc()), while the usersoace still can try interacting with the WB connector (which uses drmm_ functions). Change dpu_writeback_init() to use drmm_. Patchwork: This vulnerability occurs due to the incorrect use of different memory management functions, which can lead to data being prematurely released while still in use. A local user could exploit this during driver teardown, resulting in a use-after-free condition. This could lead to system instability or a denial of service. Red Hat severity: not rated. Weakness: CWE-825. 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.
Advisory [CVE-2026-64082] Fix register corruption from uninitialized cregs on error
In the Linux kernel, the following vulnerability has been resolved: riscv: Fix register corruption from uninitialized cregs on error compat_riscv_gpr_set() calls cregs_to_regs() unconditionally, even when user_regset_copyin() fails. Only call cregs_to_regs() when the user copy succeeds. A flaw was found in the Linux kernel, specifically within the RISC-V architecture's handling of process tracing and signal restoration. When functions like `compat_riscv_gpr_set()` or `compat_restore_sigcontext()` are invoked, they may process uninitialized stack data if a preceding user data copy operation fails. This can lead to the corruption of a task's register state and potentially leak sensitive kernel stack contents, resulting in information disclosure and a denial of service. Red Hat severity: not rated. Weakness: CWE-824. 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.
Advisory [CVE-2026-64092] fix tp_vars reference leak in receiver shutdown
In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: fix tp_vars reference leak in receiver shutdown The receiver shutdown timer handler, batadv_tp_receiver_shutdown(), is responsible for releasing the tp_vars reference it holds. However, the existing logic for coordinating this release with batadv_tp_stop_all() was flawed. timer_shutdown_sync() guarantees the timer will not fire again after it returns, but it returns non-zero only when the timer was pending at the time of the call. If the timer had already expired (and batadv_tp_stop_all() would unsucessfully try to rearm itself), batadv_tp_stop_all() skips its batadv_tp_vars_put(), and batadv_tp_receiver_shutdown() fails to put its own reference as well. Fix this by introducing a new atomic variable receiving that is set to 1 when the receiver is initialized and cleared atomically with atomic_xchg() by whichever side claims it first. Only the side that observes the transition from 1 to 0 is responsible for releasing the tp_vars timer reference, eliminating the uncertainty. A flaw was found in the Linux kernel's batman-adv module, specifically within the tp_meter component. The batadv_tp_receiver_shutdown() function, responsible for releasing tp_vars references, contains flawed logic for coordinating this release during receiver shutdown.
Advisory [CVE-2026-64100] Fix shrinker deadlock
In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix shrinker deadlock With PROVE_LOCKING on an Snapdragon X1 and VM reclaim pressure, we see: ====================================================== WARNING: possible circular locking dependency detected 7.0.0-debug+ #43 Tainted: G W ------------------------------------------------------ kswapd0/82 is trying to acquire lock: ffff800080ec3870 (reservation_ww_class_acquire){+.+.}-{0:0}, at: msm_gem_shrinker_scan+0x17c/0x400 [msm] but task is already holding lock: ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (fs_reclaim){+.+.}-{0:0}: __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 fs_reclaim_acquire+0xd0/0xf0 dma_resv_lockdep+0x224/0x348 do_one_initcall+0x84/0x5d0 do_initcalls+0x194/0x1d8 kernel_init_freeable+0x128/0x180 kernel_init+0x2c/0x160 ret_from_fork+0x10/0x20 -> #1 (reservation_ww_class_mutex){+.+.}-{4:4}: __lock_acquire+0x4d0/0xad0 lock_acquire.part.0+0xc4/0x248 lock_acquire+0x8c/0x248 dma_resv_lockdep+0x1a8/0x348 do_one_initcall+0x84/0x5d0 do_initcalls+0x194/0x1d8 kernel_init_freeable+0x128/0x180 kernel_init+0x2c/0x160 ret_from_fork+0x10/0x20 -> #0 (reservation_ww_class_acquire){+.+.}-{0:0}: check_prev_add+0x114/0x790…
Advisory [CVE-2026-64166] Check for NULL FF-A ID table while driver registration
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Check for NULL FF-A ID table while driver registration The bus match callback assumes that every FF-A driver provides an id_table and dereferences it unconditionally. Enforce that contract at registration time so a buggy client driver cannot crash the bus during match. A buggy client driver could exploit this to cause a system crash, leading to a Denial of Service (DoS). Red Hat severity: not rated. Weakness: CWE-476. 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.
Advisory [CVE-2026-64086] (pmbus/adm1266) include PEC byte in pmbus_block_xfer read buffer
In the Linux kernel, the following vulnerability has been resolved: hwmon: (pmbus/adm1266) include PEC byte in pmbus_block_xfer read buffer adm1266_pmbus_block_xfer() sets up the read transaction with.buf = data->read_buf,.len = ADM1266_PMBUS_BLOCK_MAX + 2, but read_buf in struct adm1266_data is declared as u8 read_buf[ADM1266_PMBUS_BLOCK_MAX + 1]; For a max-length block response (length byte = 255 + up to 1 PEC byte), the i2c controller is told to write 257 bytes into a 256-byte buffer, putting one byte past the end of read_buf. The same response also makes the subsequent PEC compare if (crc!= msgs[1].buf[msgs[1].buf[0] + 1]) read a byte beyond the array. Bump the read_buf declaration to ADM1266_PMBUS_BLOCK_MAX + 2 so the buffer can hold the length byte, up to 255 payload bytes, and the PEC byte the i2c_msg length already accounts for. A flaw was found in the Linux kernel's hwmon (hardware monitoring) subsystem, specifically in the pmbus/adm1266 driver. The `adm1266_pmbus_block_xfer()` function attempts to read one byte more than the allocated buffer size during a block transfer read operation. This out-of-bounds write can lead to memory corruption and potentially an information disclosure or denial of service. Red Hat severity: not rated. Weakness: CWE-787.
Advisory [CVE-2026-63949] fix OOB read on zero-length message_store
In the Linux kernel, the following vulnerability has been resolved: auxdisplay: line-display: fix OOB read on zero-length message_store() linedisp_display() unconditionally reads msg[count - 1] before checking whether count is zero, so a write of zero bytes to the message sysfs attribute hits msg[-1]: write(fd, "", 0); -> message_store(..., buf, count=0) -> linedisp_display(linedisp, buf, count=0) -> msg[count - 1] == '\n'; OOB read The kernfs write buffer for that store is a 1-byte allocation (kernfs_fop_write_iter() does kmalloc(len + 1) with len == 0), so msg[-1] is a 1-byte read before the slab object. On a KASAN-enabled kernel this trips an out-of-bounds report and panics; on stock kernels it silently reads adjacent slab data and, if that byte happens to be '\n', the following count-- wraps ssize_t 0 to -1 and is then passed to kmemdup_nul(). linedisp_display() is reached from the message_store() sysfs callback (drivers/auxdisplay/line-display.c message attribute, mode 0644) and from the in-tree initial-message setup with count == -1, so the OOB path is only userspace-triggerable via zero-byte writes; vfs_write() does not short-circuit on count == 0 and kernfs_fop_write_iter() dispatches the store callback regardless. Guard the trailing-newline trim with a count check. The existing if (!count) block then takes the clear-display path unchanged.
Advisory [CVE-2026-64074] fix slab out-of-bounds write in statmount_mnt_idmap
In the Linux kernel, the following vulnerability has been resolved: fs/statmount: fix slab out-of-bounds write in statmount_mnt_idmap statmount_mnt_idmap() writes one mapping with seq_printf() and then manually advances seq->count to include the NUL separator. If seq_printf() overflows, seq_set_overflow() sets seq->count to seq->size. The manual seq->count++ changes this to seq->size + 1. seq_has_overflowed() then no longer detects the overflow. The corrupted count returns to statmount_string(), which later executes: seq->buf[seq->count++] = '\0'; This causes a 1-byte NULL out-of-bounds write on the dynamically allocated seq buffer. Fix this by checking for overflow immediately after seq_printf(). When processing mount ID mappings, an internal buffer can be incorrectly accessed due to an unchecked overflow, leading to a single-byte overwrite. This memory corruption can cause system instability or a denial of service. Red Hat severity: not rated. Weakness: CWE-787. 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.
Advisory [CVE-2026-64075] Fix unregister_fprobe to wait for RCU grace period
In the Linux kernel, the following vulnerability has been resolved: fprobe: Fix unregister_fprobe() to wait for RCU grace period Commit 4346ba1604093 ("fprobe: Rewrite fprobe on function-graph tracer") changed fprobe to register struct fprobe to an rcu-hlist, but it forgot to wait for RCU GP. Thus there can be use-after-free if the fprobe is released right after unregistering. This can be happened on fprobe event and sample module code. To fix this issue, add synchronize_rcu() in unregister_fprobe(). Note that BPF is OK because fprobe is used as a part of bpf_kprobe_multi_link. This unregisters its fprobe in bpf_kprobe_multi_link_release() and it is deallocated via bpf_kprobe_multi_link_dealloc(), which is invoked from bpf_link_defer_dealloc_rcu_gp() RCU callback. For BPF, this also introduced unregister_fprobe_async() which does NOT wait for RCU grace priod. The 'unregister_fprobe()' function did not properly wait for the RCU (Read-Copy-Update) grace period, which is a synchronization mechanism. This oversight could lead to a use-after-free vulnerability, where memory is deallocated while still being accessed. Such a flaw can result in system instability, leading to a denial of service, and in some cases, could be exploited by a local attacker to achieve arbitrary code execution. Red Hat severity: not rated. Weakness: CWE-825.