Linux

In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 ("vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting") but was pre-existing.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate() hci_le_big_terminate() allocates iso_list_data via kzalloc_obj but returns 0 without freeing it when neither pa_sync_term nor big_sync_term flags are set after evaluating the PA and BIG sync connection state. This early-return path was introduced when hci_le_big_terminate() was refactored to take struct hci_conn instead of raw u8 parameters, adding PA/BIG flag evaluation logic. The existing kfree() on hci_cmd_sync_queue failure does not cover this path.

In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: preserve shared-frag marker in iptfs_consume_frags() iptfs_consume_frags() transfers paged fragments from one socket buffer to another but fails to propagate the SKBFL_SHARED_FRAG flag. This is the same class of bug that was fixed in skb_try_coalesce() for CVE-2026-46300: when fragments backed by read-only page-cache pages are merged, the marker indicating their shared nature must be preserved so that ESP can decide correctly whether in-place encryption is safe. Apply the same two-line fix used in skb_try_coalesce() to iptfs_consume_frags().

Integer overflow in OP-TEE OS's AES-GCM implementation silently corrupts authentication tag computation when a single operation processes more than 512 megabytes of payload or Additional Authenticated Data (AAD), affecting all deployments running versions 3.0.0 through 4.10.x on Arm TrustZone platforms. The overflow causes the GHASH length counters to wrap, meaning the GCM authentication tag is derived from incorrect bit-length values - defeating AES-GCM's core integrity guarantee without any runtime error or exception. No public exploit has been identified at time of analysis, but the practical impact for systems using OP-TEE for high-value integrity assurance (DRM, secure key storage, attestation) is significant when large payloads traverse the TEE boundary.

Subkey rollback protection in OP-TEE OS versions 3.20.0 through 4.10.x is completely non-functional due to a missing field assignment in the Trusted Application loading pipeline, allowing revoked or downgraded subkeys to authenticate TAs without detection. A locally authenticated attacker who can supply TA binaries to the REE filesystem loader can bypass the entire key-chain revocation model, loading previously invalidated trusted code into the TrustZone secure world. No public exploit has been identified at time of analysis and this is not listed in CISA KEV, but the integrity impact is categorical - the rollback database never advances, permanently defeating the control for any deployment relying on subkey-based TA signing chains.

Heap exhaustion in OP-TEE OS (versions 3.3.0 through 4.10.x) allows a low-privileged normal-world local caller to progressively degrade and ultimately deny service to all trusted applications running in the secure world. The root cause is a missing bitmask application in `cleanup_shm_refs()` that causes `mobj_reg_shm` reference objects to accumulate indefinitely on internal lists without being released. No public exploit code has been identified at time of analysis, and EPSS data was not supplied; however, the flaw is structurally straightforward to trigger through normal TEE invocation with non-contiguous shared memory parameters, making it feasible for any process with TEE access to exhaust the secure heap over time.

RSA PKCS#1 v1.5 decryption in OP-TEE's Hisilicon HPRE hardware accelerator driver exposes a Bleichenbacher-style padding oracle, allowing a local attacker to recover RSA plaintext by adaptively querying the oracle. Affected are optee_os versions 4.5.0 through 4.10.x built with Hisilicon HPRE support (CFG_HISILICON_ACC_V3=y) on Arm TrustZone-based platforms. No public exploit code or CISA KEV listing exists; exploitation is constrained by local access requirements and the high query volume characteristic of Bleichenbacher-class attacks.

RSA-OAEP decryption in OP-TEE OS versions 3.9.0 through 4.10.x exposes a Manger-style padding oracle via the NXP CAAM hardware crypto driver, enabling local low-privileged attackers to recover RSA-OAEP plaintext through approximately 1,000-2,000 adaptive chosen-ciphertext queries. The flaw arises from non-constant-time memcmp() usage during label hash verification combined with multiple distinguishable error paths that leak oracle-exploitable timing and response information. No public exploit code or CISA KEV listing has been identified at time of analysis, and exploitation is constrained to NXP CAAM-equipped platforms with the RSA driver enabled.

RSA-OAEP decryption in OP-TEE OS versions 4.5.0 through 4.10.x exposes a Manger-style padding oracle via the Hisilicon HPRE hardware crypto driver, enabling a local attacker to recover RSA-OAEP plaintext through approximately 1000-2000 adaptive chosen ciphertext queries. The root cause is a non-constant-time `memcmp()` used for label hash verification combined with distinguishable error paths - classic CWE-208 timing side-channel conditions. Impact is heavily constrained by a non-default build requirement: only Hisilicon D06 (plat-d06) hardware built with `CFG_HISILICON_ACC_V3=y` is exposed, and no public exploit or active exploitation has been identified at time of analysis.

Stack exhaustion via unbounded recursion in the OP-TEE PKCS#11 Trusted Application allows a local low-privileged user to crash the TA, causing a denial of service within the TrustZone secure world. Affected versions span 3.10.0 through 4.10.x of optee_os running on Arm Cortex-A platforms with TrustZone enabled. No active exploitation has been identified; this is a DoS-only issue with no confidentiality or integrity impact, and a patched release (4.11.0) is available.

Heap overflow in OP-TEE's ARM Crypto Extensions SHA-3 implementation corrupts TEE kernel memory across all platforms built with CFG_CRYPTO_WITH_CE82=y (ARMv8.2+ SHA3 extensions). The off-by-one error in the accelerated SHA-3 path overwrites memory beyond the hash state buffer, potentially corrupting all TEE kernel heap memory that follows. Affected versions span 3.21.0 through 4.11.0, and no public exploit has been identified at time of analysis, though the memory corruption primitive is significant in the context of a secure enclave.

In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 ("ipv6: avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.

In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().

{ // checks 253, not buffer snp_complete_psc(svm, ...); return 1; } for (idx = idx_start; idx <= idx_end; idx++) { entry_start = entries[idx]; // OOB when idx >= 2 The guest sets end_entry=10+, causing the host to iterate entries[2+] which are OOB into adjacent slab objects. For each OOB entry: - The host reads 8 bytes (OOB READ / info leak oracle) - If the data passes PSC validation, __snp_complete_one_psc() writes cur_page = 1 or 512 into the entry (OOB WRITE, sev.c:3806) - If validation fails, the error response reveals whether adjacent memory is zero vs non-zero (information disclosure to guest) The guest controls allocation size (exit_info_2), entry range (cur_entry/end_entry), and can fire unlimited VMGEXITs to repeatedly hit different slab positions. By exploiting the variety of bugs, a malicious SEV-SNP guest can: - OOB read adjacent kmalloc-cg-32 objects (heap layout disclosure) - OOB write cur_page bits into adjacent objects (heap corruption) - Trigger use-after-free conditions across VMGEXITs E.g. with KASAN enabled, a single insmod of the PoC guest module produces 73 KASAN reports: BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x126/0x890 Read of size 8 at addr ffff888219ffb5e0 by task qemu-system-x86/2199 BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x468/0x890 Write of size 8 at addr ffff888351566648 by task qemu-system-x86/2199 The buggy address belongs to the object at ffff888XXXXXXXXX which belongs to the cache kmalloc-cg-32 of size 32 The buggy address is located N bytes to the right of allocated 32-byte region [ffff888XXXXXXXXX, ffff888XXXXXXXXX) Breakdown: 62 slab-out-of-bounds (reads + writes past allocation) 7 slab-use-after-free 4 use-after-free All credit to Stan for the wonderful description and reproducer! [sean: write changelog]

In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected role Commit 0cb2af2ea66ad ("KVM: x86: Fix shadow paging use-after-free due to unexpected GFN") fixed a shadow paging mismatch between stored and computed GFNs; the bug could be triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. The rmap_remove() call would miss entries created after the PDE change because the GFN of the leaf SPTE does not match the GFN of the struct kvm_mmu_page. A similar hole however remains if the modified PDE points to a non-leaf page. In this case the gfn can be made to match, but the role does not match: the original large 2MB page creates a kvm_mmu_page with direct=1, while the new 4KB needs a kvm_mmu_page with direct=0. However, kvm_mmu_get_child_sp() does not compare the role, and therefore reuses the page. The next step is installing a leaf (4KB) SPTE on the new path which records an rmap entry under the gfn resolved by the walk. But when that child is zapped its parent kvm_mmu_page has direct=1 and kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as sp->gfn + index instead of using sp->shadowed_translation[] (or sp->gfns[] in older kernels). It therefore fails to remove the recorded entry. When the memslot is dropped the shadow page is freed but the rmap entry survives, as in the scenario that was already fixed. Code that later walks that gfn (dirty logging, MMU notifier invalidation, and so on) dereferences an sptep that lies in the freed page, causing the use-after-free.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del() bt_accept_dequeue() unlinks a not-yet-accepted child from the parent accept queue and release_sock()s it before returning, so the returned sk has no caller reference and is unlocked. l2cap_sock_cleanup_listen() walks these children on listening-socket close. A concurrent HCI disconnect drives hci_rx_work -> l2cap_conn_del() which runs l2cap_chan_del() + l2cap_sock_kill() and frees the child sk and its l2cap_chan; cleanup_listen() then uses both: BUG: KASAN: slab-use-after-free in l2cap_sock_kill l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close Freed by: l2cap_conn_del -> l2cap_sock_close_cb -> l2cap_sock_kill This is distinct from the two fixes already in this area: commit e83f5e24da741 ("Bluetooth: serialize accept_q access") serialises the accept_q list/poll and takes temporary refs inside bt_accept_dequeue(), and CVE-2025-39860 serialises the userspace close()/accept() race by calling cleanup_listen() under lock_sock() in l2cap_sock_release(). Neither covers l2cap_conn_del() running from hci_rx_work, so this UAF still reproduces on current bluetooth/master. Take the reference at the source: bt_accept_dequeue() does sock_hold() while sk is still locked, before release_sock(); callers sock_put(). cleanup_listen() pins the chan with l2cap_chan_hold_unless_zero() under a brief child sk lock (serialising vs l2cap_sock_teardown_cb()), drops it before l2cap_chan_lock(), and skips a duplicate l2cap_sock_kill() on SOCK_DEAD. conn->lock is not taken here: cleanup_listen() runs under the parent sk lock and that would invert conn->lock -> chan->lock -> sk_lock (lockdep). KASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced 12 use-after-free reports per run before this change; 0, and no lockdep report, over 1600+ raced iterations after it on bluetooth/master.

Arbitrary CWD-file read and inode-tampering in the oras-go v2 content/file tar extractor allows an attacker who controls an OCI artifact to hardlink files from the pulling process's working directory into the extract tree. When a victim runs 'oras pull' (or any Go program using oras-go/v2/content/file) against a malicious layer marked with the io.deis.oras.content.unpack annotation, the flawed ensureLinkPath helper validates a resolved hardlink target but passes the original relative Linkname to os.Link, causing link(2) to resolve it against the process CWD instead of the extract base. Publicly available exploit code exists (detailed PoC and regression test in the advisory); this is not listed in CISA KEV and no active exploitation is confirmed.

In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)

In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.

In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.

{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <TASK> check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 </TASK>

In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: <TASK> do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.

In the Linux kernel, the following vulnerability has been resolved: riscv/ptrace: Use USER_REGSET_NOTE_TYPE for REGSET_CFI Fixes a warning while dumping core: [54983.546369][ C7] WARNING: [!note_name] fs/binfmt_elf.c:1771 at elf_core_dump+0x910/0xf68, CPU#7: abort01/31982

In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.

In the Linux kernel, the following vulnerability has been resolved: ASoC: SDCA: fix NULL pointer dereference in sdca_dev_unregister_functions sdca_dev_unregister_functions() iterates over all SDCA function descriptors and calls sdca_dev_unregister() on each func_dev without checking for NULL. When a function registration has failed partway through, or the device cleanup races with probe deferral, func_dev entries may be NULL, leading to a kernel oops: BUG: kernel NULL pointer dereference, address: 0000000000000040 RIP: 0010:device_del+0x1e/0x3e0 Call Trace: sdca_dev_unregister_functions+0x37/0x60 [snd_soc_sdca] release_nodes+0x35/0xb0 devres_release_all+0x90/0x100 device_unbind_cleanup+0xe/0x80 device_release_driver_internal+0x1c1/0x200 bus_remove_device+0xc6/0x130 device_del+0x161/0x3e0 device_unregister+0x17/0x60 sdw_delete_slave+0xb6/0xd0 [soundwire_bus] sdw_bus_master_delete+0x1e/0x50 [soundwire_bus] ... sof_probe_work+0x19/0x30 [snd_sof] This was observed on a Lenovo ThinkPad X1 Carbon G14 (Panther Lake) with the SOF audio driver probe failing due to missing Panther Lake firmware, causing the subsequent cleanup of SoundWire devices to trigger the crash. Fix this with three changes: 1) Add a NULL guard in sdca_dev_unregister() so that callers do not need to pre-validate the pointer (defense in depth). 2) In sdca_dev_unregister_functions(), skip NULL func_dev entries and clear func_dev to NULL after unregistration, making the function idempotent and safe against double-invocation. 3) In sdca_dev_register_functions(), roll back all previously registered functions when a later one fails, so the function array is never left in a partially-populated state.

In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.

In the Linux kernel, the following vulnerability has been resolved: rust: arm64: set uwtable llvm module flag for CONFIG_UNWIND_TABLES Due to a rustc bug [1] the -Cforce-unwind-tables=y flag only emits the uwtable annotation for functions, but not for the module. This means that compiler-generated functions such as 'asan.module_ctor' do not receive the uwtable annotation. When CONFIG_UNWIND_PATCH_PAC_INTO_SCS is enabled, this leads to boot failures because the dwarf information emitted for the kasan constructors is wrong, which causes the SCS boot patching code to patch the constructor in an illegal manner. Specifically, the paciasp instruction is patched, but the autiasp instruction is not. This mismatch leads to a crash when the constructor is called during boot. ================================================================== BUG: KASAN: global-out-of-bounds in do_basic_setup+0x4c/0x90 Read of size 8 at addr ffffffe3cc7eb488 by task swapper/0/1 Specifically the faulting instruction is the (*fn)() to invoke the constructor in do_ctors() of the init/main.c file. Once the fix lands in rustc, this flag can be made conditional on the rustc version. Note that passing the flag on a rustc with the fix present has no effect. [ The fix [1] has landed for Rust 1.98.0 (expected release on 2026-08-20). Thus add a version check as discussed. - Miguel ] [ Adjusted link and comment. - Miguel ]

In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically "misses" a push to the dirty ring is irrelevant.

In the Linux kernel, the following vulnerability has been resolved: pinctrl: mcp23s08: Initialize mcp->dev and mcp->addr before regmap init Regmap initialization triggers regcache_maple_populate() which attempts SPI read to populate cache. SPI read requires mcp->dev and mcp->addr to be set, without them, NULL pointer dereference occurs during probe. Move initialization before mcp23s08_spi_regmap_init() call.

In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from VMAP shadow") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.

{pte,pmd,pud,p4d}_ctor(). This sets the page_type to PGTY_table, increments NR_PAGETABLE and possible allocates a PTL. However the matching pagetable_dtor() calls were never added. With DEBUG_VM enabled on kernel versions prior to v6.17 without 2dfcd1608f3a9 ("mm/page_alloc: let page freeing clear any set page type") this leads to the following warning when freeing these pages due to page->page_type sharing page->_mapcount: BUG: Bad page state in process ... pfn:284fbb page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x284fbb flags: 0x17fffc000000000(node=0|zone=2|lastcpupid=0x1ffff) page_type: f2(table) page dumped because: nonzero mapcount Call trace: bad_page+0x13c/0x160 __free_frozen_pages+0x6cc/0x860 ___free_pages+0xf4/0x180 free_pages+0x54/0x80 free_hotplug_page_range.part.0+0x58/0x90 free_empty_tables+0x438/0x500 __remove_pgd_mapping.constprop.0+0x60/0xa8 arch_remove_memory+0x48/0x80 try_remove_memory+0x158/0x1d8 offline_and_remove_memory+0x138/0x180 It can also lead to leaking the ptl allocation if ALLOC_SPLIT_PTLOCKS is defined and incorrect NR_PAGETABLE stats. Fix this by calling pagetable_dtor() in free_hotplug_pgtable_page() prior to freeing the page to undo the effects of calling pagetable_*_ctor().

In the Linux kernel, the following vulnerability has been resolved: fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh() may_decode_fh() accesses mount::mnt_ns without holding any locks; that means the mount can concurrently be unmounted, and the mnt_namespace can concurrently be freed after an RCU grace period. This race can happens as follows, assuming that the mount point was created by open_tree(..., OPEN_TREE_CLONE): thread 1 thread 2 RCU __do_sys_open_by_handle_at do_handle_open handle_to_path may_decode_fh is_mounted [mount::mnt_ns access] [mount::mnt_ns access] __do_sys_close fput_close_sync __fput dissolve_on_fput umount_tree class_namespace_excl_destructor namespace_unlock free_mnt_ns mnt_ns_tree_remove call_rcu(mnt_ns_release_rcu) mnt_ns_release_rcu mnt_ns_release kfree [mnt_namespace::user_ns access] **UAF** Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like in __prepend_path(). Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE() for writers that can race with lockless readers. This bug is unreachable unless one of the following is set: - CONFIG_PREEMPTION - CONFIG_RCU_STRICT_GRACE_PERIOD because it requires an RCU grace period to happen during a syscall without an explicit preemption. This doesn't seem to have interesting security impact; worst-case, it could leak the result of an integer comparison to userspace (from the level check in cap_capable()), cause an endless loop, or crash the kernel by dereferencing an invalid address.

In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix clock and pinctrl state inconsistency in runtime PM In i2c_imx_runtime_suspend(), the clock is disabled before switching the pinctrl state to sleep. If pinctrl_pm_select_sleep_state() fails, the runtime suspend is aborted but the clock remains disabled, causing a system crash when the hardware is subsequently accessed. Fix this by switching the pinctrl state before disabling the clock so that a pinctrl failure leaves the clock enabled and the hardware accessible. In i2c_imx_runtime_resume(), restore the pinctrl state back to sleep if clk_enable() fails to keep the consistent.

In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 <snip> Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....

In the Linux kernel, the following vulnerability has been resolved: net: airoha: Add NULL check for of_reserved_mem_lookup() in airoha_qdma_init_hfwd_queues() of_reserved_mem_lookup() may return NULL if the reserved memory region referenced by the "memory-region" phandle is not found in the reserved memory table (e.g. due to a misconfigured DTS or a removed memory-region node). The current code dereferences the returned pointer without checking for NULL, leading to a kernel NULL pointer dereference at the following lines: dma_addr = rmem->base; // line 1156 num_desc = div_u64(rmem->size, buf_size); // line 1160 Add a NULL check after of_reserved_mem_lookup() and return -ENODEV if the lookup fails, which is consistent with the existing error handling for of_parse_phandle() failure in the same code block.

In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, "slave_dev=%p:\n", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, "(slave %s): " fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.

In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.

In the Linux kernel, the following vulnerability has been resolved: mm/damon/lru_sort: handle ctx allocation failure DAMON_LRU_SORT allocates the damon_ctx object for its kdamond in its init function. damon_lru_sort_enabled_store() wrongly assumes the allocation will always succeed once tried. If the damon_ctx allocation was failed, therefore, code execution reaches to damon_commit_ctx() while 'ctx' is NULL. As a result, it dereferences the NULL 'ctx' pointer. Avoid the NULL dereference by returning -ENOMEM if 'ctx' is NULL.

{reclaim,lru_sort}: handle ctx allocation failures". DAMON_RECLAIM and DAMON_LRU_SORT could dereference NULL pointers if their damon_ctx object allocations fail. The bugs are expected to happen infrequently because the allocations are arguably too small to fail on common setups. But theoretically they are possible and the consequences are bad. Fix those. The issues were discovered [1] by Sashiko. This patch (of 2): DAMON_RECLAIM allocates the damon_ctx object for its kdamond in its init function. damon_reclaim_enabled_store() wrongly assumes the allocation will always succeed once tried. If the damon_ctx allocation was failed, therefore, code execution reaches to damon_commit_ctx() while 'ctx' is NULL. As a result, it dereferences the NULL 'ctx' pointer. Avoid the NULL dereference by returning -ENOMEM if 'ctx' is NULL.

In the Linux kernel, the following vulnerability has been resolved: mm/mincore: handle non-swap entries before !CONFIG_SWAP guard mincore_swap() also fields migration/hwpoison entries (and shmem swapin-error entries), which can exist on !CONFIG_SWAP builds when CONFIG_MIGRATION or CONFIG_MEMORY_FAILURE is enabled. The !IS_ENABLED(CONFIG_SWAP) guard ran before the non-swap-entry early return, so mincore_pte_range() can spuriously WARN and report these pages nonresident on !CONFIG_SWAP kernels. Move the guard below the non-swap-entry check so only true swap entries trip the WARN, and migration/hwpoison entries take the existing "uptodate / non-shmem" path.

In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.

{+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bounds read in dp_get_eq_aux_rd_interval() [Why & How] The aux_rd_interval array in struct dc_lttpr_caps is declared with MAX_REPEATER_CNT - 1 (7) elements, indexed 0..6. However, the offset parameter passed to dp_get_eq_aux_rd_interval() can be as large as MAX_REPEATER_CNT (8) when a sink reports 8 LTTPR repeaters via DPCD. This leads to an out-of-bounds read of aux_rd_interval[7] when offset is 8. Fix this by growing aux_rd_interval to MAX_REPEATER_CNT elements to accommodate the full range of valid repeater counts defined by the DP spec. (cherry picked from commit a55a458a8df37a65ffda5cf721d554a8f74f6b04)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as "capacity * vector->struct_size" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on NULL cgrp_moving_from in scx_cgroup_move_task() A WARN fires when systemd's user manager writes "+cpu +memory +pids" to its own subtree_control while a sched_ext scheduler is loaded: WARNING: at kernel/sched/ext.c:3227 scx_cgroup_move_task+0xa8/0xb0 scx_cgroup_move_task+0xa8/0xb0 sched_move_task+0x134/0x290 cpu_cgroup_attach+0x39/0x70 cgroup_migrate_execute+0x37d/0x450 cgroup_update_dfl_csses+0x1e3/0x270 cgroup_subtree_control_write+0x3e7/0x440 scx_cgroup_can_attach() arms cgrp_moving_from only when a task's cpu cgroup changes. It can still be NULL when scx_cgroup_move_task() runs, through this sequence: Step Result --------------------------------- ---------------------------------- 1. cpu enabled on cgroup G cpu css = A 2. cpu toggled off then on for G A killed, B created (same cgroup) 3. an exiting task keeps A alive migration skips it, A now stale 4. +memory migrates G stale A vs current B pulls cpu in 5. cpu attach runs for all tasks hits a live, cpu-unchanged task 6. scx_cgroup_move_task() on it cgrp_moving_from NULL -> WARN The mismatch is that scx_cgroup_can_attach() keys on cgroup identity while migration drives the move on css identity, so a NULL cgrp_moving_from here is a legitimate css-only migration, not a missing prep. The call is already gated on cgrp_moving_from, so just drop the warning. ops.cgroup_prep_move() and ops.cgroup_move() stay paired.

In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.

{HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage" lockdep warning message was reported to the console. During early boot, interrupts are enabled before the scheduler is enabled. In this window (before SYSTEM_SCHEDULING is set) interrupts can fire and in the hard interrupt context handler attempt to fill the pool This can lead to a deadlock when the interrupt occurred when the interrupt hits a region which holds a lock that is required to be taken in the allocation path. Add a new can_fill_pool() helper and reorder the exception rule and forbid this scenario by excluding allocations from hard interrupt context.

NULL pointer dereference in the Linux kernel's AMD64 AGP driver crashes systems running in virtualized environments without physical AMD northbridge hardware. Broken error propagation in `agp_amd64_probe()` - comparing `cache_nbs()` return value against exactly `-1` rather than `< 0` - masks the `-ENODEV` error code, allowing the driver to proceed with initialization, ultimately causing a General Protection Fault in `amd64_fetch_size()` when `node_to_amd_nb(0)` returns NULL. No public exploit has been identified at time of analysis, EPSS is 0.18% (7th percentile), and impact is confined to local denial of service via kernel crash; patches are confirmed available across multiple stable branches.

NULL pointer dereference in the Linux kernel MANA (Microsoft Azure Network Adapter) driver crashes the host kernel when initializing Virtual Function (VF) devices in VFIO passthrough or nested KVM environments where `pdev->slot` is unpopulated. Systems running affected kernel versions in Azure-style or nested virtualization deployments face deterministic kernel panics and total availability loss on the host. No public exploit code has been identified, and EPSS probability is 0.16% (5th percentile), indicating low opportunistic exploitation risk - though in targeted Azure or nested KVM environments, the crash is straightforwardly reproducible.

Deadlock in the Linux kernel's DSA (Distributed Switch Architecture) subsystem allows a local low-privileged user to hang the kernel network stack by running ethtool against a DSA-configured conduit interface. The DSA subsystem replaces the conduit device's ethtool_ops with aggregating wrappers, but these wrappers redundantly invoke netdev_lock_ops() on a lock already held by the kernel ethtool infrastructure, creating a classic double-lock deadlock. No public exploit exists and EPSS sits at 0.15% (5th percentile), though the issue is trivially reproducible with standard system tooling on affected configurations.

Resource access-after-free in the Linux kernel's vfio/pci subsystem allows a local user with device access to read or corrupt PCI device resources during a race window on device shutdown, because vfio_pci_core_close_device() disabled the function before tearing down DMABUF exports. During the window the function's Memory Space Enable bit is cleared and its BARs (and their backing resources) are freed and reassignable to another driver, while stale DMABUF mappings still reference them. EPSS is low (0.14%, 4th percentile) and there is no public exploit identified at time of analysis; the upstream fix reorders cleanup to revoke DMABUF access first.

Unbounded NAPI busy-poll loop in the Linux kernel's io_uring subsystem allows a low-privileged local process to spin the kernel indefinitely when no I/O events arrive, triggering soft lockup watchdog complaints and degrading system availability. Affected kernels are those at or after commit 8d0c12a80cdeb80d5e0510e96d38fe551ed8e9b5 (introducing NAPI support in io_uring, Linux 6.9) through the patched stable releases 6.18.33, 7.0.10, and 7.1. No public exploit exists and this is not listed in CISA KEV; EPSS sits at 0.15% (5th percentile), reflecting very low exploitation interest.

Improper input validation in the Linux kernel's nilfs2 filesystem driver allows a local low-privileged user to trigger a kernel WARN_ON and cause a denial of service by submitting a crafted ioctl request with bd_oblocknr set to zero. The zero value collides with the -ENOENT sentinel path in nilfs_ioctl_mark_blocks_dirty(), bypassing the dead block detection logic and passing an invalid block reference into nilfs_bmap_mark(). No active exploitation has been identified (EPSS 0.17%, not in CISA KEV), and patches are available across all actively maintained Linux stable branches.

Spurious WARN_ON_ONCE calls in the Linux kernel's blk-wbt subsystem trigger unnecessary kernel warnings and stack traces under expected failure conditions - memory pressure or a pre-registered writeback throttle. Local low-privileged users can provoke this via ioctl(BLKPG) during MTD partition creation under memory-constrained conditions, generating noise in kernel logs and, on panic_on_warn-enabled kernels, potentially causing a system crash. No public exploit exists and the EPSS score of 0.14% (4th percentile) places this firmly in the low-priority tier; it has not been added to CISA KEV.

NULL pointer dereference in the Linux kernel's mt76/mt7925 WiFi driver crashes the kernel when the 'sta' pointer is dereferenced before a NULL check in mt7925_tx_check_aggr(). Systems with MediaTek mt7925 WiFi hardware running affected kernel versions are exposed to a local denial-of-service via kernel panic. No public exploit exists and EPSS is at the 5th percentile (0.16%), indicating no observed widespread exploitation; patches have been applied across multiple stable kernel branches.

Firmware crash in the Linux kernel's mt76/mt7921 WiFi driver allows a local low-privileged user to cause denial of service by triggering station Association ID (AID) values above the firmware's undocumented limit of 20. Affected hardware includes Mediatek mt7922 chipsets operating in AP mode (IFTYPE_AP). Exploitation requires running a non-standard hostapd configuration that allocates AIDs starting at 65 or higher - stock hostapd is not affected. No public exploit has been identified and EPSS is 0.16% (5th percentile), indicating very low exploitation likelihood.

NULL pointer dereference in the Linux kernel's AMD RAS subsystem crashes systems with AMD GPU hardware. The function `ras_core_ras_interrupt_detected()` in `drm/amd/ras` fails to validate the `ras_core` pointer before dereferencing `ras_core->dev` in an error path, enabling a local low-privilege user to trigger a kernel panic and denial of service. No public exploit code exists and the vulnerability is not listed in CISA KEV; EPSS at 0.14% (4th percentile) confirms negligible current exploitation probability. Upstream fix commits are available in stable kernel trees.

NULL pointer dereference in the Linux kernel's drm/amd/ras subsystem allows a local low-privileged user to crash the kernel on systems with AMD GPUs. The flaw in ras_core_get_utc_second_timestamp() occurs when a NULL ras_core pointer passes a conditional check but is then dereferenced in the subsequent error-printing path, producing a kernel panic. No public exploit exists and EPSS sits at 0.15% (4th percentile), placing this firmly as a low-urgency local denial-of-service hardening issue despite the Availability:High CVSS rating.

Denial of service in the Linux kernel's padata parallel data processing subsystem results from a misplaced CPU hotplug callback that returns an error in a section where error returns are not permitted. Specifically, padata_cpu_dead() is registered below CPUHP_TEARDOWN_CPU, a hotplug state phase where callbacks are not allowed to fail; when the callback returns non-zero, the kernel emits a 'DEAD callback error' warning that can destabilize the system. A local attacker with low-privilege access on a multi-CPU system using padata (e.g., for parallel IPsec or crypto processing) can trigger this condition during CPU offline transitions, resulting in high availability impact. No public exploit is identified and EPSS is 0.16%, indicating low exploitation probability; patches are available across multiple stable kernel branches.

NULL pointer dereference in the Linux kernel AMD display driver (drm/amd/display) can cause a kernel panic on systems running AMD GPUs, resulting in a complete denial of service. The flaw resides in dc_dmub_srv_log_diagnostic_data() and dc_dmub_srv_enable_dpia_trace() in dc_dmub_srv.c, where a combined NULL guard incorrectly permits DC_LOG_ERROR() - which internally dereferences dc_dmub_srv->ctx - to execute when dc_dmub_srv itself is NULL. No public exploit has been identified at time of analysis and EPSS sits at the 4th percentile, indicating very low exploitation probability in the wild.

Integer overflow on the RISC-V IOMMU invalidation path in the Linux kernel triggers an infinite loop, causing a local denial of service. A low-privileged local user on an affected RISC-V system with IOMMU hardware can hang the kernel by inducing an invalidation where gather->end equals ULONG_MAX, exploiting the sign-extended page table range supported by RISC-V. EPSS is 0.15% (5th percentile), no active exploitation has been identified, and no public exploit code is known.

Uninitialized memory read in the Linux kernel FUSE filesystem driver causes local denial-of-service conditions. Specifically, `fuse_dentry_revalidate()` in `fs/fuse/dir.c` reads the `->d_time` field of a dentry that was allocated by `__d_alloc()` without initialization, detectable by KMSAN as a use-before-initialize defect. A local authenticated user with access to a FUSE-mounted filesystem can trigger a kernel crash by opening a file through the affected `lookup_open` → `d_revalidate` code path. No public exploit exists and EPSS is 0.15%, indicating minimal real-world exploitation pressure at this time.

Kernel page fault in the Linux kernel's Tegra234 Control Backbone (CBB) driver crashes affected NVIDIA Tegra234-based systems when a cross-fabric error interrupt triggers incorrect register address resolution. The `tegra234_cbb_get_tmo_slv()` function uses the receiving fabric's base address (`cbb->regs`) with register offsets derived from a different fabric's target map, producing an invalid virtual address dereference (`ffff80000954cc00`) and a kernel panic. Exploitation requires local low-privilege access to Tegra234 hardware; no public exploit or POC exists, EPSS sits at the 5th percentile (0.15%), and the vulnerability is not in CISA KEV.

Out-of-bounds read in the Linux kernel's OCFS2 cluster filesystem DLM (Distributed Lock Manager) stems from an off-by-one error in dlm_match_regions(), where the local-vs-remote region comparison loop uses '<=' instead of '<' and reads one entry past the valid range of the qr_regions array. It affects systems running the OCFS2 shared-disk cluster filesystem and is reachable when nodes negotiate heartbeat/region membership; the upstream tag classifies it as Information Disclosure rather than code execution. There is no public exploit identified at time of analysis, EPSS is low (0.17%, 6th percentile), and it is not in CISA KEV - despite an inflated NVD CVSS of 9.8.

Use-after-free and memory leak in the Linux kernel max77705 power supply driver expose systems with Maxim MAX77705 PMIC hardware to local denial-of-service. Two concurrent bugs exist: the workqueue is never destroyed on driver removal (memory leak), and a race condition allows an interrupt handler to schedule work on an already-freed workqueue if the interrupt fires after workqueue destruction but before the devm interface releases the interrupt registration. On vulnerable kernel versions prior to the stable-tree patches (7.0.10 and 7.1 series), a local user on hardware with a MAX77705 PMIC can trigger kernel memory corruption. No public exploit code has been identified at time of analysis, and EPSS sits at 0.14% (4th percentile), reflecting negligible opportunistic exploitation interest.

Null pointer dereference in the Linux kernel's pinctrl subsystem allows a local low-privileged attacker to crash the kernel, causing a denial of service. The flaw exists in pinconf_generic_parse_dt_pinmux(), which fails to validate that a 'pinmux' Device Tree property is non-empty before use - an empty property causes the allocator to return an invalid non-NULL pointer, and subsequent memory access triggers a kernel panic. No public exploit code exists and EPSS is 0.15% (5th percentile), reflecting low real-world exploitation probability; exploitation is further constrained to systems with specific pinctrl hardware and Device Tree configurations.

Off-by-one array overflow in the Linux kernel's hvc_iucv driver (IBM z/VM IUCV HVC terminal subsystem) can trigger an out-of-bounds write to hvc_iucv_table[8] when hvc_iucv_devices is set to the maximum value of 8, crashing the kernel. Exploitation requires local access with low privileges on IBM System z systems running z/VM with hvc_iucv configured. No public exploit identified at time of analysis; EPSS is 0.18% (7th percentile), consistent with a niche mainframe-only driver affecting a very limited deployment population.

NULL pointer dereference in the Linux kernel's ps883x USB Type-C retimer driver causes a kernel Oops during device unbind, resulting in a denial of service. The ps883x_retimer_remove() function calls i2c_get_clientdata() to retrieve driver-private state, but i2c_set_clientdata() was never called during probe, leaving the pointer NULL; dereference at offset 0x20 triggers a fatal translation fault. Systems with ps883x retimer hardware running affected kernel versions are vulnerable when a privileged local user unbinds the driver via sysfs. No active exploitation is confirmed (no CISA KEV listing), and the EPSS score of 0.17% (6th percentile) reflects negligible real-world exploitation probability.

Soft CPU lockup in the Linux kernel SCSI generic (sg) driver allows a local user to trigger a denial of service by writing an out-of-range value directly to the def_reserved_size sysfs module parameter, bypassing the validation enforced by sg_proc_write_dressz. Setting def_reserved_size to -1 via /sys/module/sg/parameters/def_reserved_size causes sg_build_reserve to enter a non-terminating allocation loop on the next open() of any /dev/sgX device, hanging the affected CPU core for 26+ seconds until the kernel watchdog fires. No public exploit code has been identified and EPSS probability is very low at 0.18%; patches are confirmed available across all active stable kernel branches.

Out-of-bounds read (CWE-125) in the Linux kernel F2FS filesystem lets a local user trigger inconsistent access to the mount extension list by racing a sysfs read against a concurrent update. The f2fs_sbi_show() handler reads extension_list, extension_count and hot_ext_count without holding sbi->sb_lock, so a simultaneous f2fs_update_extension_list() store can yield a mismatched count/array pair and drive an out-of-bounds read that leaks stale kernel data or crashes the system. No public exploit identified at time of analysis; EPSS is low (0.17%, 7th percentile) and the issue is not in CISA KEV.

NULL pointer dereference in the Linux kernel's EIP93 hardware crypto driver triggers a kernel panic during AEAD crypto operations on affected embedded systems. The root cause is a self-contradictory algorithm lookup mask in eip93_hmac_setkey() - CRYPTO_ALG_ASYNC is passed as an exclusion mask, yet EIP93 algorithms are inherently async, so the lookup always returns -ENOENT. This leaves the AEAD security association record with zeroed digest fields; any subsequent crypto operation then dereferences a NULL context pointer, crashing the kernel. No public exploit is identified at time of analysis, and EPSS is very low (0.17%, 6th percentile), reflecting the narrow hardware-specific attack surface.

Null pointer dereference in the Amlogic T7 SoC reset driver crashes the Linux kernel when uninitialized reset operation callbacks are invoked, causing a full system denial of service. Local low-privilege users on systems physically equipped with an Amlogic T7 SoC are affected across kernel versions from the introduction commit through the patched releases 6.18.33, 7.0.10, and 7.1. No public exploit has been identified and EPSS of 0.17% (6th percentile) reflects negligible real-world exploitation interest; this is a hardware-specific stability fix rather than an actively exploited security threat.

Local memory corruption in the Linux kernel's NXP ENETC (enetc) network driver stems from a DMA use-after-free in the NTMP command path: when netc_xmit_ntmp_cmd() times out, the pending hardware command is not aborted yet ntmp_free_data_mem() frees the associated DMA buffer, so the device later DMA-writes its response into the freed (possibly reallocated) physical address, producing silent kernel memory corruption. Only systems running NXP ENETC networking hardware on kernels from 6.16 through the fixed stable releases are affected. There is no public exploit identified at time of analysis, and EPSS exploitation probability is very low (0.17%, 6th percentile).

NULL pointer dereference in the Linux kernel's Airoha QDMA network driver causes a kernel panic (denial of service) when queue entry list allocation fails during TX queue initialization. Systems running Airoha-based network hardware on affected kernel versions - including Linux 6.19 - are vulnerable when the driver's cleanup path dereferences an uninitialized descriptor array pointer. No public exploit exists and EPSS sits at 0.17% (6th percentile), indicating minimal real-world exploitation activity; no CISA KEV listing.

NULL pointer dereference in the Linux kernel's airoha QDMA network driver crashes the kernel when RX queue initialization fails mid-way through allocation. The flaw exists in airoha_qdma_init_rx_queue() where early ndesc initialization causes the cleanup routine to call netif_napi_del() on NAPI structures never registered via netif_napi_add(), dereferencing a null pointer and causing a local denial of service. No public exploit identified and EPSS at 0.17% (6th percentile) reflects minimal real-world exploitation probability; impact is constrained to systems running Airoha QDMA-based network hardware.

Kernel panic via NULL pointer dereference in the Linux kernel MANA (Microsoft Azure Network Adapter) driver allows a local low-privileged user to crash the host when a power management resume failure leaves the driver in a torn-down state. The mana_remove() function is invoked twice - first during a failed mana_probe() recovery path that nullifies gdma_context and driver_data, and again when the driver is subsequently unbound - dereferencing a NULL gc pointer. No public exploit exists and EPSS is 0.17% (6th percentile), indicating minimal real-world exploitation activity; however, the impact on Azure Linux VM availability is complete (kernel panic).

Use-after-free in the Linux kernel's mailbox-test debug driver (mailbox-test.c) allows a local privileged attacker to corrupt kernel memory when the driver's probe routine fails, because previously acquired mailbox channels are not released while the devm-allocated client structure is freed anyway. The flaw carries a CVSS of 7.8 with high confidentiality, integrity, and availability impact, but exploitation is local and requires the mailbox-test module to load and hit a probe error path. No public exploit is identified at time of analysis and EPSS estimates exploitation probability at only 0.18%.

Kernel denial-of-service in the Linux mailbox subsystem triggers an OOPS when a mailbox controller is instantiated without an associated channel array and the code dereferences the missing pointer without a NULL guard. Local low-privileged users on affected systems - particularly embedded or SoC-based Linux deployments that rely on mailbox-based inter-processor communication - can cause a system crash. EPSS is 0.18% (7th percentile), no active exploitation is confirmed, and patches have been backported across all active stable branches from 5.10.x through 7.1.

Local privilege escalation potential in the Linux kernel's mailbox-test driver arises from a double-free when the RX channel is aliased to the TX channel (a valid configuration when they use different MMIO regions); the cleanup path frees the reused channel twice. Affecting the mailbox subsystem's test/debug driver across a wide range of stable branches (5.10 through 7.x), the flaw carries a 7.8 CVSS with an AV:L/PR:L vector and has an upstream fix, but EPSS is only 0.18% and there is no public exploit identified at time of analysis.

Improper locking in the Linux kernel's amdgpu DRM driver allows a local low-privileged user to trigger a kernel deadlock or system crash via the AMDGPU_INFO_READ_MMR_REG ioctl. Three distinct concurrency defects exist: inverted lock ordering between the reset semaphore and mm_lock (permitting copy_to_user() under lock), memory allocation while holding the reset semaphore, and use of down_read_trylock() where a blocking wait is required. No public exploit code has been identified and EPSS is 0.17%, placing this firmly in opportunistic-rather-than-targeted risk territory.

Kernel panic via reachable assertion in the Linux kernel Phonet subsystem allows any low-privileged local user to crash the system. The flaw exists in pn_socket_autobind() at net/phonet/socket.c:213, where a BUG_ON() assertion fires when pn_socket_bind() returns -EINVAL for a reason other than an already-bound socket - specifically, when sk->sk_state is not TCP_CLOSE on an unbound socket. This was confirmed exploitable by syzbot fuzzing. No public exploit exists independent of the syzbot reproducer, and no active exploitation is reported in CISA KEV; EPSS at the 5th percentile confirms low real-world exploitation probability.

Kernel crash via NULL pointer dereference in the ALSA HDA Conexant audio driver affects Linux kernel stable branches from 5.15 through 7.0, exploitable by a local low-privileged user on systems with Conexant HDA audio hardware. The cx_probe() function ignores the error pointer returned by snd_hda_jack_detect_enable_callback() on memory allocation failure, leaving the jack detection callback unregistered and an internal structure uninitialized; a subsequent audio jack event then triggers a kernel panic. No public exploit exists and no CISA KEV listing is present; EPSS is 0.17% (7th percentile), confirming very low real-world exploitation probability.

Use-after-free in the Linux kernel's Intel Xe GPU driver (drm/xe EU stall sampling) lets a local low-privileged user with access to the render/DRM device trigger memory corruption during stream close. In xe_eu_stall_stream_close() the driver calls drm_dev_put() before disabling the stream and freeing its resources, so if that call drops the last reference the device structures may be freed while subsequent cleanup still dereferences them. The defect is patched upstream, no public exploit is identified at time of analysis, and EPSS rates exploitation probability very low (0.17%, 6th percentile).

NULL pointer dereference in the Linux kernel ice driver's ice_reset_all_vfs() function crashes the host kernel when a Virtual Function VSI rebuild fails during concurrent NVM firmware updates on Intel E800-series NICs. Systems with SR-IOV enabled on Intel E800-series adapters running kernel versions from 5.8 through the patched stable releases are affected. An attacker or privileged local process can trigger a kernel panic by initiating a VF reset while nvmupdate64e has placed Admin Queue commands in a transitional failure state, resulting in complete host denial of service. No public exploit exists and EPSS is negligible at 0.17% (7th percentile); CISA KEV listing is absent.

Memory corruption in the arm64 early kernel mapping on Linux allows a local low-privileged user to cause a kernel panic through an off-by-one page-table allocation error introduced since commit 5973a62efa34. Affected systems running 4K page granule on arm64 hardware may have the [data, end) segment overflow into the guard gap page before early_init_stack, corrupting critical early initialization memory. No public exploit exists and EPSS is 0.17% (6th percentile), reflecting this as primarily a kernel stability and reliability concern for arm64 deployments rather than an actively weaponized attack vector.

Silent audit trail corruption in the Linux kernel's capability auditing subsystem allows a local attacker who manipulates inheritable capabilities as a precursor to privilege escalation to have that manipulation go unrecorded in CAPSET audit logs since 2008. The `__audit_log_capset()` function records `cap_effective` into the `cap_pi` (inheritable) field due to a copy-paste error, meaning compliance and forensic systems receive falsified capability state that masks the inheritable-cap modification step of a privilege escalation chain. No public exploit has been identified at time of analysis, and the EPSS score of 0.18% (7th percentile) reflects that exploitation as a standalone attack is not observed in the wild.

Memory corruption (double free and use-after-free, CWE-415) in the Linux kernel's Intel idpf network driver allows a local low-privileged actor to corrupt kernel heap memory when the auxiliary device probe error path executes. The idpf_plug_vport_aux_dev() and idpf_plug_core_aux_dev() routines free the iadev structure via a release callback during auxiliary_device_uninit(), then fall through and read adev->id from the freed object for ida_free() and kfree() it again. It is not in CISA KEV and no public exploit has been identified; EPSS exploitation probability is low at 0.17% (7th percentile).

Kernel crash in Linux DRM/AMD DCN32 display subsystem affects systems equipped with AMD RDNA3-generation GPUs running x86 non-RT kernels. The dcn32_validate_bandwidth() function locks FPU registers via DC_FP_START(), disabling local softirqs, then calls kvzalloc() for a ~335 KiB phantom-plane allocation that triggers the vmalloc path; vmalloc fires BUG_ON(in_interrupt()), crashing the kernel. No public exploit has been identified at time of analysis, and EPSS at 0.15% (5th percentile) reflects low real-world exploitation interest.