Information Disclosure

Incorrect mTLS connection reuse in libcurl (curl releases through 8.16.0) causes the library to reuse a pooled TLS connection even after client-certificate options - notably the private key - were changed in a way that should have forced a fresh handshake. Because those client-certificate settings were omitted from the connection-match logic, a later transfer can be sent over a connection authenticated with the wrong client identity, an integrity failure tagged as information disclosure. Rated CVSS 7.5 (C:N/I:H/A:N); EPSS is only 0.13% and there is no public exploit identified at time of analysis, though a HackerOne report (#3733910) drove the private disclosure.

Credential disclosure in curl 8.11.1 through 8.20.0 (and earlier) lets curl silently substitute the wrong password when .netrc lookup is combined with a URL that carries a username but no password, such as https://user@example.com/. When no matching entry exists for the specified user, curl falls back to a different user's password stored for that same host and transmits it during authentication, potentially leaking one user's secret to a server or to an unintended account. Publicly available exploit-flow details exist via the originating HackerOne report; EPSS is low (0.20%, 9th percentile) and it is not in CISA KEV.

Wrong connection reuse across different services in curl/libcurl up to 8.20.0 allows curl's connection pool to incorrectly match and reuse an existing connection when the target service differs from the one originally used to establish that connection. This is part of a coordinated batch of 19 CVEs fixed in curl 8.21.0, released June 24, 2026. No public exploit or active exploitation has been identified; the curl project rates this LOW severity, consistent with limited real-world attack surface requiring specific multi-service usage patterns.

Host key verification bypass in libcurl affects applications using the CURLOPT_SSH_KEYFUNCTION callback for SCP:// or SFTP:// transfers, where a server presenting a host key of a different type than the one already recorded in known_hosts is silently accepted instead of rejected. This lets a network-positioned attacker impersonate a trusted SSH server and mount a man-in-the-middle attack, exposing and tampering with transferred data. There is no public exploit identified at time of analysis, and the EPSS probability is low (0.19%, 9th percentile), reflecting the specific application configuration and attacker positioning required.

Cross-origin credential leakage in libcurl (curl 7.10.6 through 8.20.0) causes the HTTP Digest 'Authorization:' header computed for one origin (hostA) to be wrongly reused on a subsequent transfer to a different origin (hostB) when an application reuses the same easy handle. This exposes Digest authentication credentials to an unintended, potentially attacker-controlled host, and is tracked as an Information Disclosure issue (EUVD-2026-41501). No public exploit identified at time of analysis; EPSS is low at 0.25% (16th percentile) and it is not in CISA KEV, so this is a latent credential-exposure bug rather than a demonstrated mass-exploitation threat.

Memory-safety defect (double-free) in curl's SASL authentication path affects versions 8.15.0 through 8.20.0 when built with GSASL support: the GSASL context is cleaned up twice without the intervening pointer being cleared, causing the same allocation to be free()'d twice. A malicious or malfunctioning mail/auth server exercising the SASL handshake could trigger the condition, potentially corrupting heap memory and at minimum crashing the client. No public exploit identified at time of analysis, and the EPSS score is low (0.25%, 16th percentile) despite the headline CVSS of 9.8.

Use-after-free in libcurl 8.13.0 through 8.20.0 occurs when an application calls curl_easy_pause() from inside an event-based CURLMOPT_SOCKETFUNCTION callback, causing libcurl to write a flag through a struct pointer whose backing memory was just freed. Affected are applications built on the curl multi interface using event-based socket callbacks; the flaw can lead to memory corruption or limited information disclosure (tagged Information Disclosure) with low confidentiality, integrity, and availability impact. There is no public exploit identified at time of analysis, it is not in CISA KEV, and EPSS is low at 0.21% (11th percentile), consistent with a niche triggering pattern rather than mass exploitation.

Information disclosure in libcurl (versions 8.18.0 through 8.20.0) causes the HTTP Referer header to persist on a reused easy handle even after an application explicitly clears it by passing NULL to CURLOPT_REFERER. Because the internal referrer state is not reset, a previously set referrer string is silently re-sent on later requests, potentially leaking sensitive URL data (paths, tokens, or query parameters) to unintended destination servers. There is no public exploit identified at time of analysis, EPSS risk is low (0.21%, 11th percentile), and it is not listed in CISA KEV.

Out-of-bounds kernel memory write in the Linux kernel's OMFS filesystem driver (fs/omfs) allows a local attacker to corrupt kernel memory by mounting a crafted OMFS image. omfs_fill_super() validates that s_sys_blocksize is not larger than PAGE_SIZE but fails to enforce a lower bound, so a value below OMFS_DIR_START (0x1b8 = 440) triggers an unsigned integer underflow in omfs_make_empty(), driving a roughly 4 GiB memset() that overwrites kernel memory far beyond the block buffer. There is no public exploit identified at time of analysis, the EPSS score is low (0.18%), and it is not listed in CISA KEV; the fix has been backported across many stable kernel branches.

Local privilege-dependent use-after-free in the Linux kernel's fs/mbcache subsystem allows a privileged user (root or CAP_SYS_ADMIN) to trigger memory corruption when unmounting an ext2, ext4, or ocfs2 filesystem. mb_cache_destroy() frees the cache without cancelling the pending c_shrink_work item, so a still-running mb_cache_shrink_worker() accesses freed memory (CWE-416), potentially leading to kernel code execution or crash. No public exploit identified at time of analysis; EPSS is low (0.16%, 5th percentile) and it is not on CISA KEV.

Kernel panic via RCU locking imbalance in the DRBD subsystem's drbd_adm_dump_devices() function affects Linux kernel versions from the introduction of commit a55bbd375d18 through multiple stable branches. A locally authenticated low-privilege user who can invoke DRBD administrative operations may trigger a kernel crash by exploiting the unbalanced rcu_read_unlock() call - called without a preceding rcu_read_lock() - leading to a denial-of-service via kernel instability. No public exploit exists and EPSS probability is 0.18% (8th percentile), indicating very low real-world exploitation activity.

In the Linux kernel, the following vulnerability has been resolved: block: fix zones_cond memory leak on zone revalidation error paths When blk_revalidate_disk_zones() fails after disk_revalidate_zone_resources() has allocated args.zones_cond, the memory is leaked because no error path frees it.

In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix disk reference leak in blkcg_maybe_throttle_current() Add the missing put_disk() on the error path in blkcg_maybe_throttle_current(). When blkcg lookup, blkg lookup, or blkg_tryget() fails, the function jumps to the out label which only calls rcu_read_unlock() but does not release the disk reference acquired by blkcg_schedule_throttle() via get_device(). Since current->throttle_disk is already set to NULL before the lookup, blkcg_exit() cannot release this reference either, causing the disk to never be freed. Restore the reference release that was present as blk_put_queue() in the original code but was inadvertently dropped during the conversion from request_queue to gendisk.

In the Linux kernel, the following vulnerability has been resolved: md: fix array_state=clear sysfs deadlock When "clear" is written to array_state, md_attr_store() breaks sysfs active protection so the array can delete itself from its own sysfs store method. However, md_attr_store() currently drops the mddev reference before calling sysfs_unbreak_active_protection(). Once do_md_stop(..., 0) has made the mddev eligible for delayed deletion, the temporary kobject reference taken by sysfs_break_active_protection() can become the last kobject reference protecting the md kobject. That allows sysfs_unbreak_active_protection() to drop the last kobject reference from the current sysfs writer context. kobject teardown then recurses into kernfs removal while the current sysfs node is still being unwound, and lockdep reports recursive locking on kn->active with kernfs_drain() in the call chain. Reproducer on an existing level: 1. Create an md0 linear array and activate it: mknod /dev/md0 b 9 0 echo none > /sys/block/md0/md/metadata_version echo linear > /sys/block/md0/md/level echo 1 > /sys/block/md0/md/raid_disks echo "$(cat /sys/class/block/sdb/dev)" > /sys/block/md0/md/new_dev echo "$(($(cat /sys/class/block/sdb/size) / 2))" > \ /sys/block/md0/md/dev-sdb/size echo 0 > /sys/block/md0/md/dev-sdb/slot echo active > /sys/block/md0/md/array_state 2. Wait briefly for the array to settle, then clear it: sleep 2 echo clear > /sys/block/md0/md/array_state The warning looks like: WARNING: possible recursive locking detected bash/588 is trying to acquire lock: (kn->active#65) at __kernfs_remove+0x157/0x1d0 but task is already holding lock: (kn->active#65) at sysfs_unbreak_active_protection+0x1f/0x40 ... Call Trace: kernfs_drain __kernfs_remove kernfs_remove_by_name_ns sysfs_remove_group sysfs_remove_groups __kobject_del kobject_put md_attr_store kernfs_fop_write_iter vfs_write ksys_write Restore active protection before mddev_put() so the extra sysfs kobject reference is dropped while the mddev is still held alive. The actual md kobject deletion is then deferred until after the sysfs write path has fully returned.

In the Linux kernel, the following vulnerability has been resolved: ublk: reset per-IO canceled flag on each fetch If a ublk server starts recovering devices but dies before issuing fetch commands for all IOs, cancellation of the fetch commands that were successfully issued may never complete. This is because the per-IO canceled flag can remain set even after the fetch for that IO has been submitted - the per-IO canceled flags for all IOs in a queue are reset together only once all IOs for that queue have been fetched. So if a nonempty proper subset of the IOs for a queue are fetched when the ublk server dies, the IOs in that subset will never successfully be canceled, as their canceled flags remain set, and this prevents ublk_cancel_cmd from actually calling io_uring_cmd_done on the commands, despite the fact that they are outstanding. Fix this by resetting the per-IO cancel flags immediately when each IO is fetched instead of waiting for all IOs for the queue (which may never happen).

In the Linux kernel, the following vulnerability has been resolved: md: wake raid456 reshape waiters before suspend During raid456 reshape, direct IO across the reshape position can sleep in raid5_make_request() waiting for reshape progress while still holding an active_io reference. If userspace then freezes reshape and writes md/suspend_lo or md/suspend_hi, mddev_suspend() kills active_io and waits for all in-flight IO to drain. This can deadlock: the IO needs reshape progress to continue, but the reshape thread is already frozen, so the active_io reference is never dropped and suspend never completes. raid5_prepare_suspend() already wakes wait_for_reshape for dm-raid. Do the same for normal md suspend when reshape is already interrupted, so waiting raid456 IO can abort, drop its reference, and let suspend finish. The mdadm test tests/25raid456-reshape-deadlock reproduces the hang.

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock between reflink and transaction commit when using flushoncommit When using the flushoncommit mount option, we can have a deadlock between a transaction commit and a reflink operation that copied an inline extent to an offset beyond the current i_size of the destination node. The deadlock happens like this: 1) Task A clones an inline extent from inode X to an offset of inode Y that is beyond Y's current i_size. This means we copied the inline extent's data to a folio of inode Y that is beyond its EOF, using a call to copy_inline_to_page(); 2) Task B starts a transaction commit and calls btrfs_start_delalloc_flush() to flush delalloc; 3) The delalloc flushing sees the new dirty folio of inode Y and when it attempts to flush it, it ends up at extent_writepage() and sees that the offset of the folio is beyond the i_size of inode Y, so it attempts to invalidate the folio by calling folio_invalidate(), which ends up at btrfs' folio invalidate callback - btrfs_invalidate_folio(). There it tries to lock the folio's range in inode Y's extent io tree, but it blocks since it's currently locked by task A - during a reflink we lock the inodes and the source and destination ranges after flushing all delalloc and waiting for ordered extent completion - after that we don't expect to have dirty folios in the ranges, the exception is if we have to copy an inline extent's data (because the destination offset is not zero); 4) Task A then attempts to start a transaction to update the inode item, and then it's blocked since the current transaction is in the TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the current transaction to become unblocked (its state >= TRANS_STATE_UNBLOCKED). So task A is waiting for the transaction commit done by task B, and the later waiting on the extent lock of inode Y that is currently held by task A. Syzbot recently reported this with the following stack traces: INFO: task kworker/u8:7:1053 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:7 state:D stack:23520 pid:1053 tgid:1053 ppid:2 task_flags:0x4208060 flags:0x00080000 Workqueue: writeback wb_workfn (flush-btrfs-46) Call Trace: <TASK> context_switch kernel/sched/core.c:5298 [inline] __schedule+0x1553/0x5240 kernel/sched/core.c:6911 __schedule_loop kernel/sched/core.c:6993 [inline] schedule+0x164/0x360 kernel/sched/core.c:7008 wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline] btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914 btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline] btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704 extent_writepage fs/btrfs/extent_io.c:1852 [inline] extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline] btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713 do_writepages+0x32e/0x550 mm/page-writeback.c:2554 __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750 writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042 wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227 wb_do_writeback fs/fs-writeback.c:2374 [inline] wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414 process_one_work kernel/workqueue.c:3276 [inline] process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> INFO: task syz.4.64:6910 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz.4.64 state:D stack:22752 pid:6910 tgid: ---truncated---

In the Linux kernel, the following vulnerability has been resolved: amd-pstate: Fix memory leak in amd_pstate_epp_cpu_init() On failure to set the epp, the function amd_pstate_epp_cpu_init() returns with an error code without freeing the cpudata object that was allocated at the beginning of the function. Ensure that the cpudata object is freed before returning from the function. This memory leak was discovered by Claude Opus 4.6 with the aid of Chris Mason's AI review-prompts (https://github.com/masoncl/review-prompts/tree/main/kernel).

In the Linux kernel, the following vulnerability has been resolved: PCI: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]

In the Linux kernel, the following vulnerability has been resolved: platform/wmi: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]

In the Linux kernel, the following vulnerability has been resolved: vdpa: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]

In the Linux kernel, the following vulnerability has been resolved: s390/cio: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]

In the Linux kernel, the following vulnerability has been resolved: s390/ap: use generic driver_override infrastructure When the AP masks are updated via apmask_store() or aqmask_store(), ap_bus_revise_bindings() is called after ap_attr_mutex has been released. This calls __ap_revise_reserved(), which accesses the driver_override field without holding any lock, racing against a concurrent driver_override_store() that may free the old string, resulting in a potential UAF. Fix this by using the driver-core driver_override infrastructure, which protects all accesses with an internal spinlock. Note that unlike most other buses, the AP bus does not check driver_override in its match() callback; the override is checked in ap_device_probe() and __ap_revise_reserved() instead. Also note that we do not enable the driver_override feature of struct bus_type, as AP - in contrast to most other buses - passes "" to sysfs_emit() when the driver_override pointer is NULL. Thus, printing "\n" instead of "(null)\n". Additionally, AP has a custom counter that is modified in the corresponding custom driver_override_store().

In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]

In the Linux kernel, the following vulnerability has been resolved: perf/amd/ibs: Avoid calling perf_allow_kernel() from the IBS NMI handler Calling perf_allow_kernel() from the NMI context is unsafe and could be fatal. Capture the permission at event-initialization time by storing it in event->hw.flags, and have the NMI handler rely on that cached flag instead of making the call directly.

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix memory leaks in beacon template setup The functions ath11k_mac_setup_bcn_tmpl_ema() and ath11k_mac_setup_bcn_tmpl_mbssid() allocate memory for beacon templates but fail to free it when parameter setup returns an error. Since beacon templates must be released during normal execution, they must also be released in the error handling paths to prevent memory leaks. Fix this by using unified exit paths with proper cleanup in the respective error paths. Compile tested only. Issue found using a prototype static analysis tool and code review.

In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet The irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and scheduled when RTL_IMR_BCNINT interrupt is triggered by hardware. But it is never killed in rtl_pci_deinit(). When the rtlwifi card probe fails or is being detached, the ieee80211_hw is deallocated. However, irq_prepare_bcn_tasklet may still be running or pending, leading to use-after-free when the freed ieee80211_hw is accessed in _rtl_pci_prepare_bcn_tasklet(). Similar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to ensure that irq_prepare_bcn_tasklet is properly terminated before the ieee80211_hw is released. The issue was identified through static analysis.

Memory-safety and information-disclosure risk in the Linux kernel s390 (IBM Z) eBPF JIT compiler stems from incomplete ABI compliance: the JIT sign-extended values but never zero-extended unsigned BPF program return values and kfunc arguments as the s390x calling convention requires. On s390x hosts, a local user able to load BPF programs can cause the JIT to emit code that leaves stale upper register bits, producing incorrect computation that can leak kernel data or corrupt execution. There is no public exploit identified at time of analysis, EPSS is low (0.16%), and the issue is not in CISA KEV; it is fixed in multiple stable releases.

In the Linux kernel, the following vulnerability has been resolved: powerpc/pgtable-frag: Fix bad page state in pte_frag_destroy powerpc uses pt_frag_refcount as a reference counter for tracking it's pte and pmd page table fragments. For PTE table, in case of Hash with 64K pagesize, we have 16 fragments of 4K size in one 64K page. Patch series [1] "mm: free retracted page table by RCU" added pte_free_defer() to defer the freeing of PTE tables when retract_page_tables() is called for madvise MADV_COLLAPSE on shmem range. [1]: https://lore.kernel.org/all/7cd843a9-aa80-14f-5eb2-33427363c20@google.com/ pte_free_defer() sets the active flag on the corresponding fragment's folio & calls pte_fragment_free(), which reduces the pt_frag_refcount. When pt_frag_refcount reaches 0 (no active fragment using the folio), it checks if the folio active flag is set, if set, it calls call_rcu to free the folio, it the active flag is unset then it calls pte_free_now(). Now, this can lead to following problem in a corner case... [ 265.351553][ T183] BUG: Bad page state in process a.out pfn:20d62 [ 265.353555][ T183] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20d62 [ 265.355457][ T183] flags: 0x3ffff800000100(active|node=0|zone=0|lastcpupid=0x7ffff) [ 265.358719][ T183] raw: 003ffff800000100 0000000000000000 5deadbeef0000122 0000000000000000 [ 265.360177][ T183] raw: 0000000000000000 c0000000119caf58 00000000ffffffff 0000000000000000 [ 265.361438][ T183] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set [ 265.362572][ T183] Modules linked in: [ 265.364622][ T183] CPU: 0 UID: 0 PID: 183 Comm: a.out Not tainted 6.18.0-rc3-00141-g1ddeaaace7ff-dirty #53 VOLUNTARY [ 265.364785][ T183] Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries [ 265.364908][ T183] Call Trace: [ 265.364955][ T183] [c000000011e6f7c0] [c000000001cfaa18] dump_stack_lvl+0x130/0x148 (unreliable) [ 265.365202][ T183] [c000000011e6f7f0] [c000000000794758] bad_page+0xb4/0x1c8 [ 265.365384][ T183] [c000000011e6f890] [c00000000079c020] __free_frozen_pages+0x838/0xd08 [ 265.365554][ T183] [c000000011e6f980] [c0000000000a70ac] pte_frag_destroy+0x298/0x310 [ 265.365729][ T183] [c000000011e6fa30] [c0000000000aa764] arch_exit_mmap+0x34/0x218 [ 265.365912][ T183] [c000000011e6fa80] [c000000000751698] exit_mmap+0xb8/0x820 [ 265.366080][ T183] [c000000011e6fc30] [c0000000001b1258] __mmput+0x98/0x300 [ 265.366244][ T183] [c000000011e6fc80] [c0000000001c81f8] do_exit+0x470/0x1508 [ 265.366421][ T183] [c000000011e6fd70] [c0000000001c95e4] do_group_exit+0x88/0x148 [ 265.366602][ T183] [c000000011e6fdc0] [c0000000001c96ec] pid_child_should_wake+0x0/0x178 [ 265.366780][ T183] [c000000011e6fdf0] [c00000000003a270] system_call_exception+0x1b0/0x4e0 [ 265.366958][ T183] [c000000011e6fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec The bad page state error occurs when such a folio gets freed (with active flag set), from do_exit() path in parallel. ... this can happen when the pte fragment was allocated from this folio, but when all the fragments get freed, the pte_frag_refcount still had some unused fragments. Now, if this process exits, with such folio as it's cached pte_frag in mm->context, then during pte_frag_destroy(), we simply call pagetable_dtor() and pagetable_free(), meaning it doesn't clear the active flag. This, can lead to the above bug. Since we are anyway in do_exit() path, then if the refcount is 0, then I guess it should be ok to simply clear the folio active flag before calling pagetable_dtor() & pagetable_free().

In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix unmap race with PMD migration entries The following race is possible with migration swap entries or device-private THP entries. e.g. when move_pages is called on a PMD THP page, then there maybe an intermediate state, where PMD entry acts as a migration swap entry (pmd_present() is true). Then if an munmap happens at the same time, then this VM_BUG_ON() can happen in pmdp_huge_get_and_clear_full(). This patch fixes that. Thread A: move_pages() syscall add_folio_for_migration() mmap_read_lock(mm) folio_isolate_lru(folio) mmap_read_unlock(mm) do_move_pages_to_node() migrate_pages() try_to_migrate_one() spin_lock(ptl) set_pmd_migration_entry() pmdp_invalidate() # PMD: _PAGE_INVALID | _PAGE_PTE | pfn set_pmd_at() # PMD: migration swap entry (pmd_present=0) spin_unlock(ptl) [page copy phase] # <--- RACE WINDOW --> Thread B: munmap() mmap_write_downgrade(mm) unmap_vmas() -> zap_pmd_range() zap_huge_pmd() __pmd_trans_huge_lock() pmd_is_huge(): # !pmd_present && !pmd_none -> TRUE (swap entry) pmd_lock() -> # spin_lock(ptl), waits for Thread A to release ptl pmdp_huge_get_and_clear_full() VM_BUG_ON(!pmd_present(*pmdp)) # HITS! [ 287.738700][ T1867] ------------[ cut here ]------------ [ 287.743843][ T1867] kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:187! cpu 0x0: Vector: 700 (Program Check) at [c00000044037f4f0] pc: c000000000094ca4: pmdp_huge_get_and_clear_full+0x6c/0x23c lr: c000000000645dec: zap_huge_pmd+0xb0/0x868 sp: c00000044037f790 msr: 800000000282b033 current = 0xc0000004032c1a00 paca = 0xc000000004fe0000 irqmask: 0x03 irq_happened: 0x09 pid = 1867, comm = a.out kernel BUG at :187! Linux version 6.19.0-12136-g14360d4f917c-dirty (powerpc64le-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #27 SMP PREEMPT Sun Feb 22 10:38:56 IST 2026 enter ? for help [link register ] c000000000645dec zap_huge_pmd+0xb0/0x868 [c00000044037f790] c00000044037f7d0 (unreliable) [c00000044037f7d0] c000000000645dcc zap_huge_pmd+0x90/0x868 [c00000044037f840] c0000000005724cc unmap_page_range+0x176c/0x1f40 [c00000044037fa00] c000000000572ea0 unmap_vmas+0xb0/0x1d8 [c00000044037fa90] c0000000005af254 unmap_region+0xb4/0x128 [c00000044037fb50] c0000000005af400 vms_complete_munmap_vmas+0x138/0x310 [c00000044037fbe0] c0000000005b0f1c do_vmi_align_munmap+0x1ec/0x238 [c00000044037fd30] c0000000005b3688 __vm_munmap+0x170/0x1f8 [c00000044037fdf0] c000000000587f74 sys_munmap+0x2c/0x40 [c00000044037fe10] c000000000032668 system_call_exception+0x128/0x350 [c00000044037fe50] c00000000000d05c system_call_vectored_common+0x15c/0x2ec ---- Exception: 3000 (System Call Vectored) at 0000000010064a2c SP (7fff9b1ee9c0) is in userspace 0:mon> zh commit a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages"), enabled migration for device-private PMD entries. Hence this is one other path where this warning could get trigger from. ------------[ cut here ]------------ WARNING: arch/powerpc/mm/book3s64/hash_pgtable.c:199 at hash__pmd_hugepage_update+0x48/0x284, CPU#3: hmm-tests/1905 Modules linked in: test_hmm CPU: 3 UID: 0 PID: 1905 Comm: hmm-tests Tainted: G B W L N 7.0.0-rc1-01438-g7e2f0ee7581c #21 PREEMPT Tainted: [B]=BAD_PAGE, [W]=WARN, [L]=SOFTLOCKUP, [N]=TEST Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries NIP [c000000000096b70] hash__pmd_hugepage_update+0x48/0x284 LR [c000000000096e7c] hash__pmdp_huge_get_and_clear+0xd0/0xd4 Call Trace: [c000000604707670] [c000000004e102b8] 0xc000000004e102b8 (unreliable) [c000000604707700] [c00000000064ec3c] set_pmd_migration_entry+0x414/0x498 [c000000604707760] [c00000000063e5a4] migrate_vma_col ---truncated---

In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: don't kill URBs in interrupt context Serialization for the TX path was enforced by calling usb_kill_urb()/usb_kill_anchored_urbs(), to prevent transmission before a previous URB was completed. usb_tx_block() can be called from interrupt context (e.g. in the HCD giveback path), so we can't always use it to kill in-flight URBs. Prevent sleeping during interrupt context by checking the tx_submitted anchor for existing URBs. We now return -EBUSY, to indicate there's a pending request.

In the Linux kernel, the following vulnerability has been resolved: bpf: Do not allow deleting local storage in NMI Currently, local storage may deadlock when deferring freeing selem or local storage through kfree_rcu(), call_rcu() or call_rcu_tasks_trace() in NMI or reentrant. Since deleting selem in NMI is an unlikely use case, partially mitigate it by returning error when calling from bpf_xxx_storage_delete() helpers in NMI. Note that, it is still possible to deadlock through reentrant. A full mitigation requires returning error when irqs_disabled() is true, which, however is too heavy-handed for bpf_xxx_storage_delete(). The long-term solution requires _nolock versions of call_rcu. Another possible solution is to defer the free through irq_work [0], but it would grow the size of selem, which is non-ideal. The check is only needed in bpf_selem_unlink(), which is used by helpers and syscalls. bpf_selem_unlink_nofail() is fine as it is called during map and owner tear down that never run in NMI or reentrant. [0] https://lore.kernel.org/bpf/20260205190233.912-1-alexei.starovoitov@gmail.com/

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: prevent NULL vif dereference in mt7925_mac_write_txwi Check for a NULL `vif` before accessing `ieee80211_vif_is_mld(vif)` to avoid a potential kernel panic in scenarios where `vif` might not be initialized.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: Fix memory leak destroying device All MT76 rx queues have an associated page_pool even if the queue is not associated to a NAPI (e.g. WED RRO queues with WED enabled). Destroy the page_pool running mt76_dma_cleanup routine during module unload. Moreover returns pages to the page pool if WED is not enabled for WED RRO queues.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix potential deadlock in mt7925_roc_abort_sync roc_abort_sync() can deadlock with roc_work(). roc_work() holds dev->mt76.mutex, while cancel_work_sync() waits for roc_work() to finish. If the caller already owns the same mutex, both sides block and no progress is possible. This deadlock can occur during station removal when mt76_sta_state() -> mt76_sta_remove() -> mt7925_mac_sta_remove_link() -> mt7925_mac_link_sta_remove() -> mt7925_roc_abort_sync() invokes cancel_work_sync() while roc_work() is still running and holding dev->mt76.mutex. This avoids the mutex deadlock and preserves exactly-once work ownership.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req() mt76_connac_mcu_alloc_sta_req() allocates an skb which is expected to be freed eventually by mt76_mcu_skb_send_msg(). However, currently if an intermediate function fails before sending, the allocated skb is leaked. Specifically, mt76_connac_mcu_sta_wed_update() and mt76_connac_mcu_sta_key_tlv() may fail, leading to an immediate memory leak in the error path. Fix this by explicitly freeing the skb in these error paths. Commit 7c0f63fe37a5 ("wifi: mt76: mt7996: fix memory leak on mt7996_mcu_sta_key_tlv error") made a similar change. Compile tested only. Issue found using a prototype static analysis tool and code review.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: fix potential deadlock in mt7921_roc_abort_sync roc_abort_sync() can deadlock with roc_work(). roc_work() holds dev->mt76.mutex, while cancel_work_sync() waits for roc_work() to finish. If the caller already owns the same mutex, both sides block and no progress is possible. This deadlock can occur during station removal when mt76_sta_state() -> mt76_sta_remove() -> mt7921_mac_sta_remove() -> mt7921_roc_abort_sync() invokes cancel_work_sync() while roc_work() is still running and holding dev->mt76.mutex. This avoids the mutex deadlock and preserves exactly-once work ownership.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix deadlock in remain-on-channel mt76_remain_on_channel() and mt76_roc_complete() call mt76_set_channel() while already holding dev->mutex. Since mt76_set_channel() also acquires dev->mutex, this results in a deadlock. Use __mt76_set_channel() instead of mt76_set_channel(). Add cancel_delayed_work_sync() for mac_work before acquiring the mutex in mt76_remain_on_channel() to prevent a secondary deadlock with the mac_work workqueue.

In the Linux kernel, the following vulnerability has been resolved: bpf: Switch CONFIG_CFI_CLANG to CONFIG_CFI This was renamed in commit 23ef9d439769 ("kcfi: Rename CONFIG_CFI_CLANG to CONFIG_CFI") as it is now a compiler-agnostic option. Using the wrong name results in the code getting compiled out. Meaning the CFI failures for btf_dtor_kfunc_t would still trigger.

Memory-safety data race in the Linux kernel's BPF DEVMAP_HASH redirect path (dev_map_redirect_multi(), SKB/generic XDP path) lets a concurrent reader in softirq context observe a partially-constructed hash node because hlist_for_each_entry_safe() dereferences list pointers without the rcu_dereference() acquire barrier that pairs with writers' rcu_assign_pointer(). Affecting kernels from 5.14 up to the fixed stable releases, it can lead to memory corruption or information disclosure on weakly-ordered architectures (ARM64, POWER) when BPF devmap-hash redirect is in use. No public exploit identified at time of analysis; EPSS is low (0.18%, 7th percentile) and it is not in CISA KEV.

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix abuse of kprobe_write_ctx via freplace uprobe programs are allowed to modify struct pt_regs. Since the actual program type of uprobe is KPROBE, it can be abused to modify struct pt_regs via kprobe+freplace when the kprobe attaches to kernel functions. For example, SEC("?kprobe") int kprobe(struct pt_regs *regs) { return 0; } SEC("?freplace") int freplace_kprobe(struct pt_regs *regs) { regs->di = 0; return 0; } freplace_kprobe prog will attach to kprobe prog. kprobe prog will attach to a kernel function. Without this patch, when the kernel function runs, its first arg will always be set as 0 via the freplace_kprobe prog. To fix the abuse of kprobe_write_ctx=true via kprobe+freplace, disallow attaching freplace programs on kprobe programs with different kprobe_write_ctx values.

Local privilege/denial-of-service exposure in the Linux kernel BPF subsystem allows a low-privileged user who can load a device-bound XDP program to trigger a use-after-free during network namespace teardown. When constant blinding is enabled (bpf_jit_harden=2), JIT compilation of a BPF_F_XDP_DEV_BOUND_ONLY program clones the program and frees the original, but offload->prog is left pointing at the freed buffer; later netns cleanup dereferences it. There is no public exploit identified at time of analysis, and the EPSS probability is very low (0.17%), consistent with a config-dependent, non-default code path.

In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix error pointer dereference The function brcmf_chip_add_core() can return an error pointer and is not checked. Add checks for error pointer. Detected by Smatch: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1010 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1013 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1016 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1019 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1022 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() [add missing wifi: prefix]

Privilege-relevant memory corruption in the Linux kernel eBPF verifier (introduced around v6.11) lets a local user with BPF-loading capability defeat the verifier's range tracking when a register adds to itself (rX += rX), because adjust_reg_min_max_vals() mutates dst_reg in place and then reads the already-modified src_reg, recording a wrong delta that sync_linked_regs() propagates to linked registers. The result is a verifier-vs-runtime mismatch - the verifier reasons about register bounds that differ from actual execution, the classic precursor to out-of-bounds kernel memory access and local privilege escalation. CVSS is 7.8 (High); EPSS is low (0.17%, 6th percentile), there is no public exploit identified at time of analysis, and it is not listed in CISA KEV.

Out-of-bounds memory access in the Linux kernel networking stack (net/core qdisc segmentation path) lets a local user feed malformed GSO (Generic Segmentation Offload) packets whose headers are not present in skb->head, causing drivers and net/core/tso.c (tso_build_hdr) to memcpy beyond valid bounds. The flaw can leak adjacent kernel memory and/or crash the system; it is not in CISA KEV and no public exploit has been identified, with a low EPSS of 0.15% (5th percentile) indicating low near-term exploitation likelihood. The upstream fix adds proper header pulling via pskb_may_pull() and a new SKB_DROP_REASON_SKB_BAD_GSO drop reason so malicious packets are dropped early.

{abs,ind} instructions can take inside BTF-annotated subprograms when a packet data load fails. The verifier only validated the success path, leaving the failure path unanalyzed, which can let an unsafe BPF program pass verification. EPSS is low (0.15%, 5th percentile) and there is no public exploit identified at time of analysis, but the CVSS 7.8 (local, low-complexity) rating reflects a genuine memory-safety risk for any host where BPF program loading is reachable.

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in offloaded map/prog info fill When querying info for an offloaded BPF map or program, bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns() obtain the network namespace with get_net(dev_net(offmap->netdev)). However, the associated netdev's netns may be racing with teardown during netns destruction. If the netns refcount has already reached 0, get_net() performs a refcount_t increment on 0, triggering: refcount_t: addition on 0; use-after-free. Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains valid, they cannot prevent the netns refcount from reaching zero. Fix this by using maybe_get_net() instead of get_net(). maybe_get_net() uses refcount_inc_not_zero() and returns NULL if the refcount is already zero, which causes ns_get_path_cb() to fail and the caller to return -ENOENT -- the correct behavior when the netns is being destroyed.

Memory mishandling in the Linux kernel's Broadcom GENET (bcmgenet) Ethernet driver stems from an off-by-one error in bcmgenet_put_txcb(), where the function returned the wrong transmit control block (tx_cb) because the write pointer was rewound after reading instead of before, causing incorrect cleanup of TX descriptors. The flaw affects systems using Broadcom GENET network controllers (notably Raspberry Pi 4/5 and various Broadcom SoCs) running affected kernels prior to the stable fixes. No public exploit identified at time of analysis, and EPSS rates exploitation probability at just 0.16% (6th percentile); despite the NVD CVSS 9.8 rating, the realistic impact is local denial-of-service or limited information disclosure rather than remote unauthenticated code execution.

Denial-of-service via resource leak in the Linux kernel's Broadcom GENET (bcmgenet) Ethernet driver allows the transmit buffer-descriptor (BD) pool to be slowly exhausted. When the driver reclaims a TX queue and fast-forwards the write pointer to drop in-flight frames, those dropped frames' buffer descriptors are never returned to the free_bds pool and the netdev is not told the frames were dropped, gradually starving the TX ring until the interface can no longer transmit. There is no public exploit identified at time of analysis, EPSS is low (0.16%, 6th percentile), and a vendor (stable-tree) patch is available; the impact is availability-only (CVSS A:H, C:N/I:N).

Denial of service in the Linux kernel's Broadcom GENET (bcmgenet) Ethernet driver arises because the bcmgenet_timeout handler tears down all transmit queues when only a single queue times out, racing against queues still actively transmitting. The flaw affects systems using Broadcom GENET NICs (e.g. Raspberry Pi 4/CM4 and Broadcom set-top-box SoCs) and can lead to kernel instability or a crash under TX timeout conditions. There is no public exploit identified at time of analysis, EPSS is low (0.16%), and it is not listed in CISA KEV.

Local privilege escalation and memory corruption in the Linux kernel BPF subsystem arises from a use-after-free in the open-coded task_vma iterator, which read task->mm locklessly and took mmap_read_trylock() without ever calling mmget(). On kernels where a concurrent task exit frees the mm_struct (not protected by SLAB_TYPESAFE_BY_RCU), a BPF program iterating that task's VMAs can access freed memory, enabling information disclosure or kernel control-flow corruption. The fix has been merged upstream; there is no public exploit identified at time of analysis, EPSS is low (0.16%, 5th percentile), and it is not listed in CISA KEV.

In the Linux kernel, the following vulnerability has been resolved: bpf: return VMA snapshot from task_vma iterator Holding the per-VMA lock across the BPF program body creates a lock ordering problem when helpers acquire locks that depend on mmap_lock: vm_lock -> i_rwsem -> mmap_lock -> vm_lock Snapshot the VMA under the per-VMA lock in _next() via memcpy(), then drop the lock before returning. The BPF program accesses only the snapshot. The verifier only trusts vm_mm and vm_file pointers (see BTF_TYPE_SAFE_TRUSTED_OR_NULL in verifier.c). vm_file is reference- counted with get_file() under the lock and released via fput() on the next iteration or in _destroy(). vm_mm is already correct because lock_vma_under_rcu() verifies vma->vm_mm == mm. All other pointers are left as-is by memcpy() since the verifier treats them as untrusted.

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix RCU stall in bpf_fd_array_map_clear() Add a missing cond_resched() in bpf_fd_array_map_clear() loop. For PROG_ARRAY maps with many entries this loop calls prog_array_map_poke_run() per entry which can be expensive, and without yielding this can cause RCU stalls under load: rcu: Stack dump where RCU GP kthread last ran: CPU: 0 UID: 0 PID: 30932 Comm: kworker/0:2 Not tainted 6.14.0-13195-g967e8def1100 #2 PREEMPT(undef) Workqueue: events prog_array_map_clear_deferred RIP: 0010:write_comp_data+0x38/0x90 kernel/kcov.c:246 Call Trace: <TASK> prog_array_map_poke_run+0x77/0x380 kernel/bpf/arraymap.c:1096 __fd_array_map_delete_elem+0x197/0x310 kernel/bpf/arraymap.c:925 bpf_fd_array_map_clear kernel/bpf/arraymap.c:1000 [inline] prog_array_map_clear_deferred+0x119/0x1b0 kernel/bpf/arraymap.c:1141 process_one_work+0x898/0x19d0 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x770/0x10b0 kernel/workqueue.c:3400 kthread+0x465/0x880 kernel/kthread.c:464 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x19/0x30 arch/x86/entry/entry_64.S:245 </TASK>

In the Linux kernel, the following vulnerability has been resolved: net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf sixpack_receive_buf() does not properly skip bytes with TTY error flags. The while loop iterates through the flags buffer but never advances the data pointer (cp), and passes the original count (including error bytes) to sixpack_decode(). This causes sixpack_decode() to process bytes that should have been skipped due to TTY errors. The TTY layer does not guarantee that cp[i] holds a meaningful value when fp[i] is set, so passing those positions to sixpack_decode() results in KMSAN reporting an uninit-value read. Fix this by processing bytes one at a time, advancing cp on each iteration, and only passing valid (non-error) bytes to sixpack_decode(). This matches the pattern used by slip_receive_buf() and mkiss_receive_buf() for the same purpose.

Local privilege escalation in the Linux kernel (6.11 through pre-patch 6.12.x/6.18.x/7.0.x) arises from a BPF verifier state-pruning flaw in regsafe() handling of BPF_ADD_CONST scalar registers, where base register IDs are not checked for mapping consistency. An attacker able to load BPF programs can construct two verifier states that falsely appear equivalent, causing state pruning to incorrectly succeed and letting an unsafe program bypass verification. With CVSS 7.8 (AV:L/PR:L) and full C/I/A impact, successful exploitation can corrupt kernel memory; there is no public exploit identified at time of analysis and EPSS is low (0.16%).

In the Linux kernel, the following vulnerability has been resolved: net_sched: fix skb memory leak in deferred qdisc drops When the network stack cleans up the deferred list via qdisc_run_end(), it operates on the root qdisc. If the root qdisc do not implement the TCQ_F_DEQUEUE_DROPS flag the packets queue to free are never freed and gets stranded on the child's local to_free list. Fix this by making qdisc_dequeue_drop() aware of the root qdisc. It fetches the root qdisc and check for the TCQ_F_DEQUEUE_DROPS flag. If the flag is present, the packet is appended directly to the root's to_free list. Otherwise, drop it directly as it was done before the optimization was implemented.

Out-of-bounds read and kernel pointer leak in the Linux kernel's eBPF sock_ops subsystem lets a local low-privileged actor able to load BPF programs disclose kernel memory and corrupt kernel state. The SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register on the !fullsock/!locked_tcp_sock path when dst_reg == src_reg, leaving a stale ctx pointer that the verifier mistakes for a valid socket or a scalar. There is no public exploit identified at time of analysis, and EPSS exploitation probability is low (0.14%, 4th percentile).

Improper network-namespace isolation in the Linux kernel's net/rds InfiniBand transport (RDS/IB) lets a local user operating in a non-initial network namespace trigger faulty RDS/IB behavior, because the existing code was never written to function correctly outside the initial netns. The upstream fix restricts RDS/IB to the initial network namespace entirely. NVD rates it 7.8 (local, low-privilege); EPSS is low at 0.16% (6th percentile) and there is no public exploit identified at time of analysis.

Local privilege escalation in the Linux kernel's PPP driver allows an unprivileged user to issue network-administration ioctls against a network namespace they should not control. The /dev/ppp device authorizes opens against the file owner's user namespace (f_cred->user_ns) while unattached administrative ioctls act on current->nsproxy->net_ns, so a user who creates a new user namespace via CLONE_NEWUSER and gains CAP_NET_ADMIN only there can still invoke PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited (parent) network namespace. No public exploit identified at time of analysis, and EPSS is low (0.26%, 17th percentile), indicating no current evidence of mass exploitation.

In the Linux kernel, the following vulnerability has been resolved: bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb bpf_prog_test_run_skb() calls eth_type_trans() first and then uses skb->protocol to initialize sk family and address fields for the test run. For IPv4 and IPv6 packets, it may access ip_hdr(skb) or ipv6_hdr(skb) even when the provided test input only contains an Ethernet header. Reject the input earlier if the Ethernet frame carries IPv4/IPv6 EtherType but the L3 header is too short. Fold the IPv4/IPv6 header length checks into the existing protocol switch and return -EINVAL before accessing the network headers.

Use-after-free in the Linux kernel Bluetooth subsystem allows kernel memory corruption when the HCI connection-request handler (hci_conn_request_evt()) invokes hci_connect_cfm() without holding hdev->lock under the HCI_PROTO_DEFER path. An adjacent attacker within Bluetooth range can race a concurrent connection teardown against a deferred-setup SCO listener to free and reuse the conn object, yielding high confidentiality, integrity, and availability impact (CVSS 8.8). There is no public exploit identified at time of analysis and EPSS is low (0.16%, 6th percentile), reflecting the narrow, race-dependent trigger rather than broad exploitability.

Race-condition memory corruption in the Linux kernel Bluetooth L2CAP stack lets a nearby BLE device crash or potentially compromise an affected host. The l2cap_ecred_reconf_rsp() handler calls l2cap_chan_del() without first taking l2cap_chan_lock(), so a crafted L2CAP Enhanced Credit (ECRED) reconfiguration response can mutate the channel list while another kernel thread iterates it. The flaw carries a vendor CVSS of 8.8 but a very low EPSS (0.16%, 6th percentile), is not in CISA KEV, and no public exploit has been identified at time of analysis; a vendor patch is available.

Denial-of-service (packet drops and severe throughput degradation) affects the Linux kernel SCTP-over-UDP encapsulation path, where udp_tunnel_xmit_skb()/udp_tunnel6_xmit_skb() were called without disabling bottom halves. After the xmit recursion-limit change (commit 6f1a9140ecda), the unbalanced per-CPU dev_xmit_recursion_inc/dec pairing can misdetect recursion and drop packets in ip(6)_tunnel_xmit() or __dev_queue_xmit(). CVSS 7.5 (A:H) reflects availability impact only; EPSS is low (0.14%, 4th percentile) and there is no public exploit identified at time of analysis.

In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-ep-msi: Fix error unwind and prevent double alloc pci_epf_alloc_doorbell() stores the allocated doorbell message array in epf->db_msg/epf->num_db before requesting MSI vectors. If MSI allocation fails, the array is freed but the EPF state may still point to freed memory. Clear epf->db_msg and epf->num_db on the MSI allocation failure path so that later cleanup cannot double-free the array and callers can retry allocation. Also return -EBUSY when doorbells have already been allocated to prevent leaking or overwriting an existing allocation.

In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: backend: fix error pointer dereference The function drm_atomic_get_plane_state() can return an error pointer and is not checked for it. Add error pointer check. Detected by Smatch: drivers/gpu/drm/sun4i/sun4i_backend.c:496 sun4i_backend_atomic_check() error: 'plane_state' dereferencing possible ERR_PTR()

In the Linux kernel, the following vulnerability has been resolved: ASoC: sti: use managed regmap_field allocations The regmap_field objects allocated at player init are never freed and may leak resources if the driver is removed. Switch to devm_regmap_field_alloc() to automatically limit the lifetime of the allocations the lifetime of the device.

In the Linux kernel, the following vulnerability has been resolved: dm cache: fix write hang in passthrough mode The invalidate_remove() function has incomplete logic for handling write hit bios after cache invalidation. It sets up the remapping for the overwrite_bio but then drops it immediately without submission, causing write operations to hang. Fix by adding a new invalidate_committed() continuation that submits the remapped writes to the cache origin after metadata commit completes, while using the overwrite_endio hook to ensure proper completion sequencing. This maintains existing coherency. Also improve error handling in invalidate_complete() to preserve the original error status instead of using bio_io_error() unconditionally.

Concurrent cache-block invalidation in the Linux kernel's device-mapper dm-cache `smq` policy (running in passthrough mode) corrupts shared state because the `invalidate_mapping` operation is invoked from multiple workers without locking. This produces data races on the allocated-blocks counter and use-after-free conditions in internal data structures during concurrent writes, enabling local memory corruption with potential for privilege escalation or denial of service. There is no public exploit identified at time of analysis, and the EPSS probability is very low (0.18%, 7th percentile), consistent with a hard-to-trigger local race rather than a remotely weaponizable flaw.

In the Linux kernel, the following vulnerability has been resolved: dm cache: fix dirty mapping checking in passthrough mode switching As mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), dm-cache assumed table reload occurs after suspension, while LVM's table preload breaks this assumption. The dirty mapping check for passthrough mode was designed around this assumption and is performed during table creation, causing the check to fail with preload while metadata updates are ongoing. This risks loading dirty mappings into passthrough mode, resulting in data loss. Reproduce steps: 1. Create a writeback cache with zero migration_threshold to produce dirty mappings dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writeback smq \ 2 migration_threshold 0" 2. Preload a table in passthrough mode dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" 3. Write to the first cache block to make it dirty fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 4. Resume the inactive table. Now it's possible to load the dirty block into passthrough mode. dmsetup resume cache Fix by moving the checks to the preresume phase to support table preloading. Also remove the unused function dm_cache_metadata_all_clean.

In the Linux kernel, the following vulnerability has been resolved: dm cache metadata: fix memory leak on metadata abort retry When failing to acquire the root_lock in dm_cache_metadata_abort because the block_manager is read-only, the temporary block_manager created outside the root_lock is not properly released, causing a memory leak. Reproduce steps: This can be reproduced by reloading a new table while the metadata is read-only. While the second call to dm_cache_metadata_abort is caused by lack of support for table preload in dm-cache, mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), it exposes the memory leak in dm_cache_metadata_abort when the function is called multiple times. Specifically, dm-cache fails to sync the new cache object's mode during preresume, creating the reproducer condition. This issue could also occur through concurrent metadata_operation_failed calls due to races in cache mode updates, but the table preload scenario below provides a reliable reproducer. 1. Create a cache device with some faulty trailing metadata blocks dmsetup create cmeta <<EOF 0 200 linear /dev/sdc 0 200 7992 error EOF dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 131072 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 1 writethrough smq 0" 2. Suspend and resume the cache to start a new metadata transaction and trigger metadata io errors on the next metadata commit. dmsetup suspend cache dmsetup resume cache 3. Write to the cache device to update metadata fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0 --direct=1 --size 64k 4. Preload the same table dmsetup reload cache --table "$(dmsetup table cache)" 5. Resume the new table. This triggers the memory leak. dmsetup suspend cache dmsetup resume cache kmemleak logs: <snip> unreferenced object 0xffff8880080c2010 (size 16): comm "dmsetup", pid 132, jiffies 4294982580 hex dump (first 16 bytes): 00 38 b9 07 80 88 ff ff 6a 6b 6b 6b 6b 6b 6b a5 ... backtrace (crc 3118f31c): kmemleak_alloc+0x28/0x40 __kmalloc_cache_noprof+0x3d9/0x510 dm_block_manager_create+0x51/0x140 dm_cache_metadata_abort+0x85/0x320 metadata_operation_failed+0x103/0x1e0 cache_preresume+0xacd/0xe70 dm_table_resume_targets+0xd3/0x320 __dm_resume+0x1b/0xf0 dm_resume+0x127/0x170 <snip>

Privilege/isolation bypass in the Linux kernel RISC-V IOMMU driver allows a local low-privileged actor to leverage stale address translations because the driver failed to issue mandatory TLB and context-cache invalidations (IOTINVAL) after updating Device Directory Table (DDT) or Page Directory Table (PDT) entries. Affecting RISC-V platforms running kernels prior to the stable fixes (6.18.33, 7.0.10, 7.1), the gap can let a device or its controlling principal access memory outside its intended IOMMU domain, breaking DMA isolation. There is no public exploit identified at time of analysis, EPSS risk is low (0.17%, 6th percentile), and it is not in CISA KEV.

Use-after-free in the Linux kernel's HiSilicon SEC2 crypto accelerator driver (crypto/hisilicon/sec2) allows local memory corruption when, under heavy load, the hardware completes and frees a request (req) before the software transmission path finishes referencing it. The fix replaces the freed req with the longer-lived qp_ctx pointer. There is no public exploit identified at time of analysis and EPSS exploitation probability is low (0.17%); despite an NVD-style CVSS of 9.8, this is a local hardware-specific race rather than a remote, network-reachable flaw.

Local memory-corruption in the Linux kernel's drm/msm (Qualcomm Adreno GPU) driver stems from a VM_BIND UNMAP locking bug where a wrong argument left the GPU buffer objects involved in UNMAP operations unlocked. A low-privileged local user with GPU/render access on systems using the msm driver can trigger races that, per the 7.8 CVSS vector (AV:L/AC:L/PR:L), yield high confidentiality, integrity, and availability impact. No public exploit identified at time of analysis, and EPSS is low at 0.17%, indicating limited near-term mass-exploitation likelihood.

Improper DMA-alias handling in the Linux kernel's AMD IOMMU driver lets a stale or incorrect Device Table Entry (DTE) be propagated to an alias PCI device, weakening the DMA isolation the IOMMU is meant to enforce. The flaw affects systems on AMD platforms where pci_for_each_dma_alias() supplies an alias-rather than the original-device to clone_alias(), causing the wrong source devid to be used when copying the DTE. EPSS is low (0.17%, 6th percentile) and there is no public exploit identified at time of analysis.

In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: qdsp6: topology: check widget type before accessing data Check widget type before accessing the private data, as this could a virtual widget which is no associated with a dsp graph, container and module. Accessing witout check could lead to incorrect memory access.

In the Linux kernel, the following vulnerability has been resolved: PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on When PERST# is deasserted twice (assert -> deassert -> assert -> deassert), a CBB (Control Backbone) timeout occurs at DBI register offset 0x8bc (PCIE_MISC_CONTROL_1_OFF). This happens because pci_epc_deinit_notify() and dw_pcie_ep_cleanup() are called before reset_control_deassert() powers on the controller core. The call chain that causes the timeout: pex_ep_event_pex_rst_deassert() pci_epc_deinit_notify() pci_epf_test_epc_deinit() pci_epf_test_clear_bar() pci_epc_clear_bar() dw_pcie_ep_clear_bar() __dw_pcie_ep_reset_bar() dw_pcie_dbi_ro_wr_en() <- Accesses 0x8bc DBI register reset_control_deassert(pcie->core_rst) <- Core powered on HERE The DBI registers, including PCIE_MISC_CONTROL_1_OFF (0x8bc), are only accessible after the controller core is powered on via reset_control_deassert(pcie->core_rst). Accessing them before this point results in a CBB timeout because the hardware is not yet operational. Fix this by moving pci_epc_deinit_notify() and dw_pcie_ep_cleanup() to after reset_control_deassert(pcie->core_rst), ensuring the controller is fully powered on before any DBI register accesses occur.

Local privilege escalation and memory-corruption risk in the Linux kernel disk quota subsystem arises from a use-after-free race between dquot_scan_active() and quota deactivation in quota_release_workfn(). On affected kernels (multiple stable trees from 4.19 through 6.x/7.x), a dquot can be acquired by the scan path after being placed on the releasing list with dq_count==0, so under memory pressure the caller may operate on a freed dquot, corrupting kernel memory. EPSS is low (0.18%, 7th percentile) and there is no public exploit identified at time of analysis; the issue requires local access with low privileges per the CVSS vector.

Concurrency-induced data corruption in the Linux kernel GFS2 cluster filesystem occurs because gfs2_logd() invokes the log-flushing helpers gfs2_ail1_start(), gfs2_ail1_wait(), and gfs2_ail1_empty() without holding sdp->sd_log_flush_lock, allowing these routines to race with concurrent journal transactions that the lock is meant to serialize. The defect affects systems mounting GFS2 volumes and is fixed by adding a non-locking __gfs2_log_flush() helper and acquiring sd_log_flush_lock in gfs2_logd before flushing. No public exploit identified at time of analysis, and EPSS is low (0.17%, 7th percentile), consistent with a local filesystem race rather than a remotely weaponizable flaw despite the input's 9.8 score.

Incorrect DLL-enable logic in the Linux kernel's Tegra124 External Memory Controller (EMC) driver (drivers/memory/tegra/tegra124-emc) caused a reversed check of the EMRS register's A0 bit, which determines whether the memory DLL is enabled (DLL is on when A0 is low). On affected NVIDIA Tegra124 SoC platforms this could mis-program DRAM timing during frequency scaling, leading to memory instability rather than a remotely triggerable compromise. The fix has been backported across stable trees; no public exploit identified at time of analysis, and EPSS is very low (0.18%, 7th percentile).

Out-of-bounds memory access in the Linux kernel's NVIDIA Tegra Control Backbone (CBB) driver (soc/tegra: cbb) stems from an incorrect ARRAY_SIZE calculation in the fabric lookup tables, which can be triggered during a target timeout lookup on Tegra-based systems. A local, low-privileged attacker on affected Tegra hardware could read out-of-bounds kernel memory (information disclosure) or crash the system (denial of service), with CVSS 7.1. The flaw has been fixed upstream; there is no public exploit identified at time of analysis and EPSS is low at 0.17% (6th percentile).

In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate group add input before caching [BUG] OCFS2_IOC_GROUP_ADD can trigger a BUG_ON in ocfs2_set_new_buffer_uptodate(): kernel BUG at fs/ocfs2/uptodate.c:509! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_set_new_buffer_uptodate+0x194/0x1e0 fs/ocfs2/uptodate.c:509 Code: ffffe88f 42b9fe4c 89e64889 dfe8b4df Call Trace: ocfs2_group_add+0x3f1/0x1510 fs/ocfs2/resize.c:507 ocfs2_ioctl+0x309/0x6e0 fs/ocfs2/ioctl.c:887 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7bbfb55a966d [CAUSE] ocfs2_group_add() calls ocfs2_set_new_buffer_uptodate() on a user-controlled group block before ocfs2_verify_group_and_input() validates that block number. That helper is only valid for newly allocated metadata and asserts that the block is not already present in the chosen metadata cache. The code also uses INODE_CACHE(inode) even though the group descriptor belongs to main_bm_inode and later journal accesses use that cache context instead. [FIX] Validate the on-disk group descriptor before caching it, then add it to the metadata cache tracked by INODE_CACHE(main_bm_inode). Keep the validation failure path separate from the later cleanup path so we only remove the buffer from that cache after it has actually been inserted. This keeps the group buffer lifetime consistent across validation, journaling, and cleanup.

In the Linux kernel, the following vulnerability has been resolved: ima_fs: Correctly create securityfs files for unsupported hash algos ima_tpm_chip->allocated_banks[i].crypto_id is initialized to HASH_ALGO__LAST if the TPM algorithm is not supported. However there are places relying on the algorithm to be valid because it is accessed by hash_algo_name[]. On 6.12.40 I observe the following read out-of-bounds in hash_algo_name: ================================================================== BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440 Read of size 8 at addr ffffffff83e18138 by task swapper/0/1 CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3 Call Trace: <TASK> dump_stack_lvl+0x61/0x90 print_report+0xc4/0x580 ? kasan_addr_to_slab+0x26/0x80 ? create_securityfs_measurement_lists+0x396/0x440 kasan_report+0xc2/0x100 ? create_securityfs_measurement_lists+0x396/0x440 create_securityfs_measurement_lists+0x396/0x440 ima_fs_init+0xa3/0x300 ima_init+0x7d/0xd0 init_ima+0x28/0x100 do_one_initcall+0xa6/0x3e0 kernel_init_freeable+0x455/0x740 kernel_init+0x24/0x1d0 ret_from_fork+0x38/0x80 ret_from_fork_asm+0x11/0x20 </TASK> The buggy address belongs to the variable: hash_algo_name+0xb8/0x420 Memory state around the buggy address: ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9 ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9 ^ ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9 ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 ================================================================== Seems like the TPM chip supports sha3_256, which isn't yet in tpm_algorithms: tpm tpm0: TPM with unsupported bank algorithm 0x0027 That's TPM_ALG_SHA3_256 == 0x0027 from "Trusted Platform Module 2.0 Library Part 2: Structures", page 51 [1]. See also the related U-Boot algorithms update [2]. Thus solve the problem by creating a file name with "_tpm_alg_<ID>" postfix if the crypto algorithm isn't initialized. This is how it looks on the test machine (patch ported to v6.12 release): # ls -1 /sys/kernel/security/ima/ ascii_runtime_measurements ascii_runtime_measurements_tpm_alg_27 ascii_runtime_measurements_sha1 ascii_runtime_measurements_sha256 binary_runtime_measurements binary_runtime_measurements_tpm_alg_27 binary_runtime_measurements_sha1 binary_runtime_measurements_sha256 policy runtime_measurements_count violations [1]: https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf [2]: https://lists.denx.de/pipermail/u-boot/2024-July/558835.html

In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: fix deadlock in hid_post_reset() You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them.

Local memory corruption / control-flow corruption in the Linux kernel arm64 BPF JIT stems from an off-by-one in the check_imm() branch-displacement range check, which lets a forward branch be silently rewritten into a backward branch when a B.cond/CBZ/CBNZ (imm19) or B/BL (imm26) displacement falls in the over-permissive extra bit of range. A local user able to load a BPF program on arm64 can trigger miscompiled JIT code that corrupts kernel control flow, with potential for code execution, data corruption, or denial of service. EPSS is low (0.18%, 8th percentile), with no public exploit identified at time of analysis and no CISA KEV listing.

The Linux kernel's BPF sockmap subsystem deadlocks when a BPF iterator program iterating over AF_UNIX sockets via `bpf_iter_unix_seq_show()` simultaneously attempts to update a sockmap entry during the same execution context. When `lock_sock_fast()` takes the spinlock fast path and holds `slock-AF_UNIX`, any subsequent `sock_map_update_elem()` call within the BPF iterator program spins indefinitely attempting to re-acquire the same spinlock on the same CPU, causing an unrecoverable kernel deadlock and loss of system availability. This is not confirmed actively exploited (not in CISA KEV), no public exploit has been identified, and EPSS at 0.17% (7th percentile) confirms negligible current exploitation interest; the real-world risk is constrained to specialized BPF workloads with specific capability requirements.

Local privilege escalation via a use-after-free in the Linux kernel's BPF sockmap subsystem (unix_stream_bpf_update_proto) allows a local attacker with BPF/sockmap privileges to corrupt kernel memory by racing a BPF iterator program against an AF_UNIX socket close. The flaw is a race condition where the `peer` pointer becomes stale during a TCP_ESTABLISHED→TCP_CLOSE transition, leading to a sock_hold() on freed memory (confirmed by a KASAN slab-use-after-free report). With a CVSS of 7.8 (local, low complexity, low privileges) it carries high confidentiality, integrity, and availability impact, though EPSS is low (0.19%) and there is no public exploit identified at time of analysis.

Memory corruption in the Linux kernel BPF arena subsystem (versions 6.9 through pre-patch 7.1) arises because arena_alloc_pages() accepts an attacker-controlled NUMA node_id as a plain int and forwards it through the entire page-allocation chain without bounds validation. A local user able to load BPF programs and invoke the bpf_arena_alloc_pages helper can supply an out-of-range node_id, leading to out-of-bounds access into per-node allocator structures with potential information disclosure, corruption, or denial of service. There is no public exploit identified at time of analysis and the EPSS exploitation probability is low (0.17%, 6th percentile).

In the Linux kernel, the following vulnerability has been resolved: i3c: master: renesas: Fix memory leak in renesas_i3c_i3c_xfers() The xfer structure allocated by renesas_i3c_alloc_xfer() was never freed in the renesas_i3c_i3c_xfers() function. Use the __free(kfree) cleanup attribute to automatically free the memory when the variable goes out of scope.

Uninitialized variable read in the NTFS3 filesystem driver (`ntfs_iomap_begin()`) of the Linux kernel allows a local authenticated user to crash the system by triggering a zero-length run condition that causes the `lcn` (logical cluster number) variable to be consumed before assignment. The flaw affects Linux 7.0 up to 7.0.10 and Linux 7.1 prior to the stable fix commits, with the defect discovered and confirmed by Google syzbot via KMSAN. No public exploit has been identified and EPSS probability is very low (0.17%, 7th percentile); patches are available in Linux 7.0.10 and 7.1.

Kernel availability impact in the Linux NTFS3 filesystem driver allows a local low-privileged user to trigger a WARN_ON(1) in attr_data_get_block_locked() by accessing NTFS volumes containing compressed or sparse attributes with frame-aligned cluster boundaries. The root cause is a missing run-segment load for vcn0 when it resides in a different attribute segment than vcn after cmask rounding, causing run_lookup_entry() to return SPARSE_LCN and fire the kernel warning. No public exploit has been identified and EPSS is 0.15% (5th percentile), confirming this as a low-probability exploitation target despite the confirmed vendor patch.