Linux

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.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix use-after-free bugs in mt7915_mac_dump_work() When the mt7915 pci chip is detaching, the mt7915_crash_data is released in mt7915_coredump_unregister(). However, the work item dump_work may still be running or pending, leading to UAF bugs when the already freed crash_data is dereferenced again in mt7915_mac_dump_work(). The race condition can occur as follows: CPU 0 (removal path) | CPU 1 (workqueue) mt7915_pci_remove() | mt7915_sys_recovery_set() mt7915_unregister_device() | mt7915_reset() mt7915_coredump_unregister() | queue_work() vfree(dev->coredump.crash_data) | mt7915_mac_dump_work() | crash_data-> // UAF Fix this by ensuring dump_work is properly canceled before the crash_data is deallocated. Add cancel_work_sync() in mt7915_unregister_device() to synchronize with any pending or executing dump work.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix use-after-free bugs in mt7996_mac_dump_work() When the mt7996 pci chip is detaching, the mt7996_crash_data is released in mt7996_coredump_unregister(). However, the work item dump_work may still be running or pending, leading to UAF bugs when the already freed crash_data is dereferenced again in mt7996_mac_dump_work(). The race condition can occur as follows: CPU 0 (removal path) | CPU 1 (workqueue) mt7996_pci_remove() | mt7996_sys_recovery_set() mt7996_unregister_device() | mt7996_reset() mt7996_coredump_unregister() | queue_work() vfree(dev->coredump.crash_data) | mt7996_mac_dump_work() | crash_data-> // UAF Fix this by ensuring dump_work is properly canceled before the crash_data is deallocated. Add cancel_work_sync() in mt7996_unregister_device() to synchronize with any pending or executing dump work.

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.

{ 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: cls_fw: fix NULL dereference of "old" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 ("net: sched: protect filter_chain list with filter_chain_lock mutex") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the "old" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: > -A 4.3.2.1 -B 1.2.3.4 -t udp "dp=1234" -q & > action skbedit mark 65536 continue can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: <TASK> tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 </TASK> irq event stamp: 1045778 hardirqs last enabled at (1045784): [<ffffffff864ec042>] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [<ffffffff864ec027>] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [<ffffffff874d48c7>] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [<ffffffff874fe8f8>] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip "old-style" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw "old-style" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---

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.

Out-of-bounds kernel memory read in the Linux kernel's eBPF subsystem (pcpu_init_value) lets a local, low-privileged user with BPF access leak adjacent kernel memory and potentially crash the system. The flaw triggers when a per-CPU map is updated from a BPF_MAP_TYPE_CGROUP_STORAGE map whose value_size is not 8-byte aligned (e.g. 4 bytes), causing copy_map_value_long to read past the true source size. The issue is fixed in stable kernels; there is no public exploit identified at time of analysis and EPSS exploitation probability is very low (0.16%, 5th percentile).

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.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error When hci_register_dev() fails in hci_uart_register_dev() HCI_UART_PROTO_INIT is not cleared before calling hu->proto->close(hu) and setting hu->hdev to NULL. This means incoming UART data will reach the protocol-specific recv handler in hci_uart_tty_receive() after resources are freed. Clear HCI_UART_PROTO_INIT with a write lock before calling hu->proto->close() and setting hu->hdev to NULL. The write lock ensures all active readers have completed and no new reader can enter the protocol recv path before resources are freed. This allows the protocol-specific recv functions to remove the "HCI_UART_REGISTERED" guard without risking a null pointer dereference if hci_register_dev() fails.

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.

Denial of service in the Linux kernel network/BPF subsystem allows a NULL-pointer dereference and kernel panic via xdp_master_redirect() when XDP frames are redirected through a bonding master that was never brought up. Because bpf_master_redirect_enabled_key is a global static key, attaching native XDP to any bond device system-wide enables the XDP_TX→xdp_master_redirect() interception for every slave, letting traffic reach bond_rr_gen_slave_id() against a round-robin bond whose per-CPU rr_tx_counter is still NULL (allocated only in bond_open()). Exploitation probability is low (EPSS 0.16%, 6th percentile) and there is no public exploit identified at time of analysis, but the original crash was discovered and reproduced by syzkaller.

Out-of-bounds memory access in the Linux kernel's Arm Mali 'komeda' DRM display driver allows a local low-privileged user to bypass AFBC framebuffer size validation via an integer overflow, supplying an undersized GEM buffer object that the driver treats as valid. Exploitation requires local access to the DRM device on hardware using the komeda driver, and there is no public exploit identified at time of analysis; EPSS probability is very low (0.16%, 6th percentile). The flaw was found by the Linux Verification Center using SVACE static analysis and is fixed across multiple stable kernel series.

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 null-deref with concurrent writes in passthrough mode In passthrough mode, when dm-cache starts to invalidate a cache entry and bio prison cell lock fails due to concurrent write to the same cached block, mg->cell remains NULL. The error path in invalidate_complete() attempts to unlock and free the cell unconditionally, causing a NULL pointer dereference: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 UID: 0 PID: 134 Comm: fio Not tainted 6.19.0-rc7 #3 PREEMPT RIP: 0010:dm_cell_unlock_v2+0x3f/0x210 <snip> Call Trace: invalidate_complete+0xef/0x430 map_bio+0x130f/0x1a10 cache_map+0x320/0x6b0 __map_bio+0x458/0x510 dm_submit_bio+0x40e/0x16d0 __submit_bio+0x419/0x870 <snip> Reproduce steps: 1. Create a cache device 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 writethrough smq 0" 2. Promote the first data block into cache fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the first cached block concurrently fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0 --direct=1 --numjobs=2 --size 64k Fix by checking if mg->cell is valid before attempting to unlock it.

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>

Out-of-bounds kernel heap write in the Linux kernel's device-mapper dm-log module (dm_log) lets a privileged local actor corrupt vmalloc-allocated memory by overflowing a 32-bit region_count. In create_log_context(), dm_sector_div_up() returns a 64-bit sector_t that is truncated into an unsigned int, so a dm target with very large ti->len and small region_size under-allocates the clean_bits/sync_bits/recovering_bits bitsets while later log operations index the full untruncated region space. Tracked as CVE-2026-53059 (CWE-190) with CVSS 7.0; there is no public exploit identified at time of analysis and it is not listed in CISA KEV, though the upstream report includes a working reproducer and a confirmed kernel crash.

In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cadence: cdns-mhdp8546-core: Set the mhdp connector earlier in atomic_enable() In case if we get errors in cdns_mhdp_link_up() or cdns_mhdp_reg_read() in atomic_enable, we will go to cdns_mhdp_modeset_retry_fn() and will hit NULL pointer while trying to access the mutex. We need the connector to be set before that. Unlike in legacy cases with flag !DRM_BRIDGE_ATTACH_NO_CONNECTOR, we do not have connector initialised in bridge_attach(), so add the mhdp->connector_ptr in device structure to handle both cases with DRM_BRIDGE_ATTACH_NO_CONNECTOR and !DRM_BRIDGE_ATTACH_NO_CONNECTOR, set it in atomic_enable() earlier to avoid possible NULL pointer dereference in recovery paths like modeset_retry_fn() with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set.

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.

In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: fix mismatch between power and frequency During DPU runtime suspend, calling dev_pm_opp_set_rate(dev, 0) drops the MMCX rail to MIN_SVS while the core clock frequency remains at its original (highest) rate. When runtime resume re-enables the clock, this may result in a mismatch between the rail voltage and the clock rate. For example, in the DPU bind path, the sequence could be: cpu0: dev_sync_state -> rpmhpd_sync_state cpu1: dpu_kms_hw_init timeline 0 ------------------------------------------------> t After rpmhpd_sync_state, the voltage performance is no longer guaranteed to stay at the highest level. During dpu_kms_hw_init, calling dev_pm_opp_set_rate(dev, 0) drops the voltage, causing the MMCX rail to fall to MIN_SVS while the core clock is still at its maximum frequency. When the power is re-enabled, only the clock is enabled, leading to a situation where the MMCX rail is at MIN_SVS but the core clock is at its highest rate. In this state, the rail cannot sustain the clock rate, which may cause instability or system crash. Remove the call to dev_pm_opp_set_rate(dev, 0) from dpu_runtime_suspend to ensure the correct vote is restored when DPU resumes. Patchwork: https://patchwork.freedesktop.org/patch/710077/

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.

In the Linux kernel, the following vulnerability has been resolved: gfs2: prevent NULL pointer dereference during unmount When flushing out outstanding glock work during an unmount, gfs2_log_flush() can be called when sdp->sd_jdesc has already been deallocated and sdp->sd_jdesc is NULL. Commit 35264909e9d1 ("gfs2: Fix NULL pointer dereference in gfs2_log_flush") added a check for that to gfs2_log_flush() itself, but it missed the sdp->sd_jdesc dereference in gfs2_log_release(). Fix that.

In the Linux kernel, the following vulnerability has been resolved: efi/capsule-loader: fix incorrect sizeof in phys array reallocation The krealloc() call for cap_info->phys in __efi_capsule_setup_info() uses sizeof(phys_addr_t *) instead of sizeof(phys_addr_t), which might be causing an undersized allocation. The allocation is also inconsistent with the initial array allocation in efi_capsule_open() that allocates one entry with sizeof(phys_addr_t), and the efi_capsule_write() function that stores phys_addr_t values (not pointers) via page_to_phys(). On 64-bit systems where sizeof(phys_addr_t) == sizeof(phys_addr_t *), this goes unnoticed. On 32-bit systems with PAE where phys_addr_t is 64-bit but pointers are 32-bit, this allocates half the required space, which might lead to a heap buffer overflow when storing physical addresses. This is similar to the bug fixed in commit fccfa646ef36 ("efi/capsule-loader: fix incorrect allocation size") which fixed the same issue at the initial allocation site.

Denial-of-service (NULL-pointer dereference / use-after-free) in the Linux kernel's in-kernel SMB3 server (ksmbd) affects systems that offload SMB3 message encryption to asynchronous hardware crypto engines such as the Qualcomm Crypto Engine (QCE). ksmbd_crypt_message() installs a NULL completion callback and misinterprets the -EINPROGRESS return from async AEAD requests as a fatal error, freeing the request while the hardware DMA is still running so the later qce_skcipher_done() callback dereferences freed memory and crashes the kernel. There is no public exploit identified at time of analysis, it is not in CISA KEV, and EPSS is low (0.18%, 8th percentile), consistent with the narrow hardware/configuration prerequisites despite the NVD CVSS of 9.8.

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).

Out-of-bounds memory read in the Linux kernel's OCFS2 distributed lock manager (dlm_match_regions) lets a remote host send a crafted DLM_QUERY_REGION message whose attacker-controlled qr_numregions field (up to 255) drives loops past the fixed 1024-byte/32-entry qr_regions buffer. Because the o2net transport only checks message byte length and not field values, this enables disclosure of adjacent kernel memory and likely node crashes. There is no public exploit identified at time of analysis and EPSS exploitation probability is low (0.18%, 7th percentile); the issue is fixed across multiple stable kernel branches.

In the Linux kernel, the following vulnerability has been resolved: fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal CXL is linked before fwctl in drivers/Makefile. Both use `module_init, so `cxl_pci_driver_init()` runs first. When `cxl_pci_probe()` calls `fwctl_register()` and then `device_add()`, fwctl_class is not yet registered because fwctl_init() hasn't run, causing `class_to_subsys()` to return NULL and skip knode_class initialization. On device removal, `class_to_subsys()` returns non-NULL, and `device_del()` calls `klist_del()` on the uninitialized knode, triggering a NULL pointer dereference.

Memory-safety failure in the Linux kernel OCFS2 filesystem's listxattr() path allows a local low-privileged user to crash the kernel (and potentially leak adjacent kernel heap memory) when an OCFS2 inode carries both inline and block-based extended attributes. Introduced by refactor commit 936b8834366e, the bug causes copy_to_user() to be invoked with a length larger than the allocated list buffer, tripping the hardened usercopy check (kernel BUG at mm/usercopy.c:102). EPSS is low (0.18%, 7th percentile), there is no public exploit identified at time of analysis, and it is not in CISA KEV.

Out-of-bounds memory read in the Linux kernel's OCFS2 filesystem driver allows a local user to leak kernel memory or crash the system by issuing the OCFS2_IOC_INFO ioctl with the OCFS2_INFO_FL_NON_COHERENT flag against a crafted or malicious OCFS2 image. The non-coherent freefrag scan path trusts the on-disk bg_bits group-descriptor field as a bitmap limit without validation, driving the bitmap walk past the end of the block buffer. No public exploit identified at time of analysis, and EPSS is low (0.18%, 7th percentile), consistent with a local, filesystem-mount-dependent kernel bug rather than a remotely scanned threat.

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): 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.

Null pointer dereference in the Linux kernel's BPF sockmap subsystem allows a local low-privileged user to crash the system via a race condition between AF_UNIX socket connection and sockmap proto update. The flaw exists because unix_stream_connect() sets sk_state to TCP_ESTABLISHED before assigning the peer pointer, creating a window where unix_stream_bpf_update_proto() dereferences unix_peer(sk) while it is still NULL. No public exploit exists and EPSS sits at the 8th percentile; this is not in CISA KEV, and the narrow race window constrains practical exploitation.

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.

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL deref in map_kptr_match_type for scalar regs Commit ab6c637ad027 ("bpf: Fix a bpf_kptr_xchg() issue with local kptr") refactored map_kptr_match_type() to branch on btf_is_kernel() before checking base_type(). A scalar register stored into a kptr slot has no btf, so the btf_is_kernel(reg->btf) call dereferences NULL. Move the base_type() != PTR_TO_BTF_ID guard before any reg->btf access.

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.

Error pointer dereference in the Linux kernel USB Type-C TI Power Delivery (tipd) driver allows a local low-privileged user to crash the kernel (denial of service) on systems with TI CD321x or TPS6598x USB Type-C controller hardware. The flaw in `cd321x_update_work()` at `drivers/usb/typec/tipd/core.c:827` logs a warning when `typec_register_partner()` fails but omits an early return, causing a subsequent unconditional dereference of the error pointer via `typec_partner_set_identity()`. No public exploit code has been identified at time of analysis, EPSS probability is 0.17% (6th percentile), and the vulnerability is not listed in CISA KEV.

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.

Denial of service in the Linux kernel's NFSD (in-kernel NFSv4 server) arises from an nfs4_file reference-count leak in nfsd4_add_rdaccess_to_wrdeleg, where __nfs4_file_get_access is wrongly called even when another thread has already taken READ access on the file. The leaked fi_access count keeps the backing nfsd_file pinned, so stopping the nfs-server service triggers a kernel BUG in kmem_cache_destroy() because nfsd_file objects remain on cache shutdown. The flaw affects systems running the in-kernel NFS server (fixed in 6.18.33, 7.0.10, and 7.1); there is no public exploit identified at time of analysis and EPSS exploitation probability is low (0.17%).

Use-after-free in the Linux kernel's greybus 'raw' driver (drivers/staging/greybus/raw.c) allows a local user holding an open character-device handle to trigger memory corruption when the underlying raw bundle is disconnected and the application later closes the cdev. The flaw stems from the gb_raw structure (which embeds the cdev) being freed in the disconnect callback while a userspace reference remains, causing cdev_put to operate on freed memory and a refcount underflow/panic, especially with CONFIG_INIT_ON_FREE_DEFAULT_ON=y. No public exploit identified at time of analysis, and EPSS is low (0.16%, 6th percentile), consistent with a local, niche-driver issue.

Local privilege-level denial of service in the Linux kernel's Greybus 'raw' character device driver (gb_raw) allows a user with access to the chardev to trigger a use-after-free by writing to the device after a disconnect has freed the underlying gb_connection object, causing a kernel NULL pointer dereference and panic (observed reliably with CONFIG_INIT_ON_FREE_DEFAULT_ON=y). The flaw is a race between the raw_write() path calling gb_operation_sync_timeout() and gb_connection_destroy() running during disconnect. EPSS is low (0.16%, 6th percentile) with no public exploit identified at time of analysis and no CISA KEV listing.

Missing NUL termination in the Linux kernel's ntfs3 filesystem driver allows a local attacker with filesystem mount privileges to trigger an out-of-bounds memory read, crashing the kernel. The defect in ntfs_fill_super() leaves sbi->volume.label unterminated when a UTF-16 volume label converts to a UTF-8 string that exactly fills the fixed buffer, causing ntfs3_label_show() to read past the buffer boundary via a %s format specifier. No public exploit has been identified at time of analysis and EPSS sits at 0.17% (7th percentile), indicating very low current exploitation interest despite the High availability impact in CVSS.

Unbounded string concatenation in the Linux kernel's Dell WMI BIOS interface driver (dell-wmi-sysman) allows a local low-privileged attacker on Dell hardware to crash the kernel. The populate_enum_data() function bounds each individual firmware-provided string but applies no remaining-space check during cumulative strcat() calls into fixed 512-byte struct members, enabling a buffer overflow that results in complete system availability loss. With an EPSS of 0.17% (7th percentile), no public exploit code, and no CISA KEV listing, this is a low-likelihood but straightforward local denial-of-service on Dell platforms running unpatched kernel versions.

Integer overflow in the Linux kernel SCSI target core allows a local attacker with low privileges to crash the kernel via crafted UNMAP commands. The `sbc_execute_unmap()` function performs a capacity bounds check on LBA + range but fails to guard against 64-bit wraparound, meaning an attacker can supply values that overflow to bypass the check and trigger a kernel panic. No public exploit code or CISA KEV listing exists; EPSS is 0.18% (7th percentile), reflecting the niche attack surface limited to systems actively running SCSI target daemons. Patches are confirmed available across all supported stable kernel branches.

Local privilege escalation or memory disclosure is possible in the User Mode Linux (UML/'um') architecture of the Linux kernel (affected around 6.19, fixed in 7.0.10 and 7.1) due to a TLB-sync race condition where the page table is traversed and modified without holding the page table lock. Concurrent threads in the same process can corrupt page table state, with CVSS 7.8 (local, low-privilege) and a high-impact triad; there is no public exploit identified at time of analysis and EPSS is low at 0.15% (5th percentile), consistent with a hard-to-trigger local race rather than a mass-exploited flaw.

Kernel panic in the SpaceMIT clock controller driver (`clk-spacemit-ccu`) can be triggered during CPU frequency scaling on systems running SpaceMIT RISC-V hardware. The root cause is an inverted boolean condition in `ccu_mix_trigger_fc()` that causes the frequency change trigger to be skipped at the wrong time and fired at the wrong time, crashing the kernel under normal cpufreq governor activity. Exploitation requires only local low-privilege access, but is practically limited to the narrow hardware footprint of SpaceMIT K1-based boards; no public exploit or CISA KEV listing exists, and EPSS is 0.17% (6th percentile).

Kernel panic in the Linux f2fs garbage collector allows a local low-privileged user to crash the system by triggering a VM_BUG_ON_FOLIO assertion when GC attempts to re-read a page already marked uptodate after multiple block relocations. The affected subsystem is f2fs (Flash-Friendly File System); systems using ext4, XFS, or other filesystems are not impacted. EPSS is extremely low (0.17%, 6th percentile) and no active exploitation has been identified, making this a stability/DoS concern primarily relevant to mobile, embedded, and flash-storage Linux deployments.

Data loss in the Linux kernel's f2fs (Flash-Friendly File System) driver exposes files created and synced before any checkpoint has been written to permanent loss on sudden power off. The race condition between fsync on newly created files and concurrent checkpoint operations causes f2fs_need_inode_block_update() to misread prematurely set nat_entry flags (IS_CHECKPOINTED and HAS_LAST_FSYNC), leading fsync to skip the inode block flush it actually requires. No public exploit identified at time of analysis; the EPSS score of 0.16% at the 6th percentile reflects the narrow triggering conditions and local-only attack surface.