Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix UAF read of tail-&gt;len in unix_stream_data_wait()<br /> <br /> unix_stream_data_wait() does skb_peek_tail(&amp;sk-&gt;sk_receive_queue) without<br /> holding any lock that prevents SKBs on that queue from being dequeued and<br /> freed.<br /> This has been the case since commit 79f632c71bea ("unix/stream: fix<br /> peeking with an offset larger than data in queue").<br /> The first consequence of this is that the pointer comparison<br /> `tail != last` can be false even if `last` semantically refers to an<br /> already-freed SKB while `tail` is a new SKB allocated at the same address;<br /> which can cause unix_stream_data_wait() to wrongly keep blocking after new<br /> data has arrived, but only in a weird scenario where a peeking recv() and<br /> a normal recv() on the same socket are racing, which is probably not a<br /> real problem.<br /> <br /> But since commit 2b514574f7e8 ("net: af_unix: implement splice for stream<br /> af_unix sockets"), `tail` is actually dereferenced, which can cause UAF in<br /> the following race scenario (where test_setup() runs single-threaded,<br /> and afterwards, test_thread1() and test_thread2() run concurrently in<br /> two threads:<br /> ```<br /> static int socks[2];<br /> void test_setup(void) {<br /> socketpair(AF_UNIX, SOCK_STREAM, 0, socks);<br /> send(socks[1], "A", 1, 0);<br /> int peekoff = 1;<br /> setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &amp;peekoff, sizeof(peekoff));<br /> }<br /> void test_thread1(void) {<br /> char dummy;<br /> recv(socks[0], &amp;dummy, 1, MSG_PEEK);<br /> }<br /> void test_thread2(void) {<br /> char dummy;<br /> recv(socks[0], &amp;dummy, 1, 0);<br /> shutdown(socks[1], SHUT_WR);<br /> }<br /> ```<br /> <br /> when racing like this:<br /> ```<br /> thread1 thread2<br /> unix_stream_read_generic<br /> mutex_lock(&amp;u-&gt;iolock)<br /> skb_peek(&amp;sk-&gt;sk_receive_queue)<br /> skb_peek_next(skb, &amp;sk-&gt;sk_receive_queue)<br /> mutex_unlock(&amp;u-&gt;iolock)<br /> unix_stream_read_generic<br /> unix_state_lock(sk)<br /> skb_peek(&amp;sk-&gt;sk_receive_queue)<br /> unix_state_unlock(sk)<br /> unix_stream_data_wait<br /> unix_state_lock(sk)<br /> tail = skb_peek_tail(&amp;sk-&gt;sk_receive_queue)<br /> spin_lock(&amp;sk-&gt;sk_receive_queue.lock)<br /> __skb_unlink(skb, &amp;sk-&gt;sk_receive_queue)<br /> spin_unlock(&amp;sk-&gt;sk_receive_queue.lock)<br /> consume_skb(skb) [frees the SKB]<br /> `tail != last`: false<br /> `tail`: true<br /> `tail-&gt;len != last_len` ***UAF***<br /> ```<br /> <br /> Fix the UAF by removing the read of tail-&gt;len; checking tail-&gt;len would<br /> only make sense if SKBs in the receive queue of a UNIX socket could grow,<br /> which can no longer happen.<br /> <br /> Kuniyuki explained:<br /> <br /> &gt; When commit 869e7c62486e ("net: af_unix: implement stream sendpage<br /> &gt; support") added sendpage() support, data could be appended to the last<br /> &gt; skb in the receiver&amp;#39;s queue.<br /> &gt;<br /> &gt; That&amp;#39;s why we needed to check if the length of the last skb was changed<br /> &gt; while waiting for new data in unix_stream_data_wait().<br /> &gt;<br /> &gt; However, commit a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") and<br /> &gt; commit 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use<br /> &gt; MSG_SPLICE_PAGES") refactored sendmsg(), and now data is always added<br /> &gt; to a new skb.<br /> <br /> That means this fix is not suitable for kernels before 6.5.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: fix potential skb leak in igc_fpe_xmit_smd_frame()<br /> <br /> When igc_fpe_init_tx_descriptor() fails, no one takes care of an<br /> allocated skb, leaking it. [1]<br /> Use dev_kfree_skb_any() on failure.<br /> <br /> Tested on an I226 adapter with the following command, while injecting<br /> faults in igc_fpe_init_tx_descriptor() to trigger the error path.<br /> # ethtool --set-mm $DEV verify-enabled on tx-enabled on pmac-enabled on<br /> <br /> [1]<br /> unreferenced object 0xffff888113c6cdc0 (size 224):<br /> ...<br /> backtrace (crc be3d3fda):<br /> kmem_cache_alloc_node_noprof+0x3b1/0x410<br /> __alloc_skb+0xde/0x830<br /> igc_fpe_xmit_smd_frame.isra.0+0xad/0x1b0<br /> igc_fpe_send_mpacket+0x37/0x90<br /> ethtool_mmsv_verify_timer+0x15e/0x300

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits<br /> <br /> Userspace can restore an ITS Device Table Entry whose Size field encodes<br /> more EventID bits than the virtual ITS supports. The live MAPD path<br /> rejects that state, but vgic_its_restore_dte() accepts it and stores the<br /> out-of-range value in dev-&gt;num_eventid_bits.<br /> <br /> Reject restored DTEs with num_eventid_bits &gt; VITS_TYPER_IDBITS before<br /> allocating the device. This mirrors the MAPD check and prevents the<br /> restored state from reaching vgic_its_restore_itt(), where the unchecked<br /> value can be converted into an oversized scan_its_table() range.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virt: sev-guest: Explicitly leak pages in unknown state<br /> <br /> When set_memory_{encrypted,decrypted}() fail, the user cannot know at which<br /> point the function failed, meaning that the pages are left in an unknown state<br /> from the point of view of the caller.<br /> <br /> Since the pages may be left in an unencrypted state, they are not suitable for<br /> general use, and cannot be returned safely to the buddy allocator. Avoid the<br /> issue by never freeing the pages, and then do the proper accounting by calling<br /> snp_leak_pages().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: vgic: Free private_irqs when init fails after allocation<br /> <br /> Companion to commit 250f25367b58 ("KVM: arm64: Tear down vGIC on<br /> failed vCPU creation"), which added the missing kvm_vgic_vcpu_destroy()<br /> call to the kvm_share_hyp() failure path in kvm_arch_vcpu_create(). The<br /> kvm_vgic_vcpu_init() failure path immediately above it has the same<br /> shape and still needs the same cleanup.<br /> <br /> Call kvm_vgic_vcpu_destroy() when kvm_vgic_vcpu_init() fails so private<br /> IRQs allocated before a redistributor iodev registration failure are<br /> released before the failed vCPU is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: isci: Fix use-after-free in device removal path<br /> <br /> The ISCI completion tasklet is initialized in isci_host_alloc()<br /> (drivers/scsi/isci/init.c:496) and scheduled from both MSI-X and legacy<br /> interrupt handlers (drivers/scsi/isci/host.c:223,613).<br /> <br /> isci_host_deinit() stops the controller and waits for stop completion,<br /> but it never kills completion_tasklet before teardown continues. A<br /> top-of-function tasklet_kill() is not sufficient here: interrupts are<br /> only disabled when isci_host_stop_complete() runs, so until<br /> wait_for_stop() returns the IRQ handlers can still requeue the<br /> tasklet. The tasklet callback also re-enables interrupts after draining<br /> completions, so killing the tasklet before the source is quiesced leaves<br /> the same race open.<br /> <br /> Once wait_for_stop() returns, no further IRQ-driven scheduling can<br /> occur. Kill completion_tasklet there so teardown cannot race a queued<br /> tasklet running on a dead ihost. On remove or unload, the stale callback<br /> can otherwise dereference ihost and touch ihost-&gt;smu_registers after the<br /> host lifetime ends.<br /> <br /> A UML + KASAN analogue reproduced the failure class both with no<br /> tasklet_kill() and with tasklet_kill() placed before source quiesce, and<br /> stayed clean once the kill happened after quiescing the scheduling<br /> source.<br /> <br /> This mirrors commit f6ab594672d4 ("scsi: aic94xx: fix use-after-free in<br /> device removal path"), but ISCI needs the kill after wait_for_stop().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/siw: Reject MPA FPDU length underflow before signed receive math<br /> <br /> A malicious connected siw peer can send an iWARP FPDU whose MPA length<br /> field (c_hdr-&gt;mpa_len, 16 bit big-endian, peer-controlled) is smaller<br /> than the fixed DDP/RDMAP header for the announced opcode. Soft-iWARP<br /> parses the full header in siw_get_hdr() based on iwarp_pktinfo[opcode]<br /> .hdr_len, but never compares mpa_len against that header length.<br /> <br /> siw_tcp_rx_data() then derives<br /> <br /> srx-&gt;fpdu_part_rem = be16_to_cpu(mpa_len) - fpdu_part_rcvd<br /> + MPA_HDR_SIZE;<br /> <br /> where fpdu_part_rcvd equals iwarp_pktinfo[opcode].hdr_len at this<br /> point. For a tagged WRITE (hdr_len 16, MPA_HDR_SIZE 2) the smallest<br /> on-wire mpa_len of 0 yields fpdu_part_rem = -14, and any mpa_len below<br /> hdr_len - MPA_HDR_SIZE underflows to a negative int.<br /> <br /> The signed value then flows into siw_proc_write()/siw_proc_rresp() as<br /> <br /> bytes = min(srx-&gt;fpdu_part_rem, srx-&gt;skb_new);<br /> <br /> is handed to siw_check_mem() as an int len (whose interval check<br /> addr + len &gt; mem-&gt;va + mem-&gt;len is satisfied for a valid base when<br /> len is negative), and reaches siw_rx_data() -&gt; siw_rx_kva() /<br /> siw_rx_umem() -&gt; skb_copy_bits() as a signed copy length. The header<br /> copy branch in skb_copy_bits() promotes that to size_t, producing a<br /> multi-gigabyte read.<br /> <br /> KASAN under a KUnit harness that drives the real kernel TCP receive<br /> path -- a loopback AF_INET socketpair, the malformed FPDU written via<br /> kernel_sendmsg, sk_data_ready firing in softirq, tcp_read_sock<br /> dispatching to siw_tcp_rx_data -- reports:<br /> <br /> BUG: KASAN: use-after-free in skb_copy_bits+0x284/0x480<br /> Read of size 4294967295 at addr ffff888...<br /> Call Trace:<br /> skb_copy_bits<br /> siw_rx_kva<br /> siw_rx_data<br /> siw_check_mem<br /> siw_proc_write<br /> siw_tcp_rx_data<br /> __tcp_read_sock<br /> siw_qp_llp_data_ready<br /> tcp_data_ready<br /> tcp_data_queue<br /> <br /> Add the missing invariant at the earliest point where the peer header<br /> is fully assembled. iwarp_pktinfo[*].hdr_len - MPA_HDR_SIZE is exactly<br /> the value the siw transmitter uses as the minimum mpa_len for each<br /> opcode (drivers/infiniband/sw/siw/siw_qp.c:33), so this matches the<br /> protocol contract. Out-of-range FPDUs terminate the connection with<br /> TERM_ERROR_LAYER_LLP / LLP_ETYPE_MPA / LLP_ECODE_FPDU_START -- which<br /> is RFC 5044 Section 8 error code 3 ("Marker and ULPDU Length fields<br /> do not agree on the start of an FPDU"), the correct framing-error<br /> class for this inconsistency.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix shrinker deadlock<br /> <br /> With PROVE_LOCKING on an Snapdragon X1 and VM reclaim pressure, we see:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 7.0.0-debug+ #43 Tainted: G W<br /> ------------------------------------------------------<br /> kswapd0/82 is trying to acquire lock:<br /> ffff800080ec3870 (reservation_ww_class_acquire){+.+.}-{0:0}, at: msm_gem_shrinker_scan+0x17c/0x400 [msm]<br /> <br /> but task is already holding lock:<br /> ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #2 (fs_reclaim){+.+.}-{0:0}:<br /> __lock_acquire+0x4d0/0xad0<br /> lock_acquire.part.0+0xc4/0x248<br /> lock_acquire+0x8c/0x248<br /> fs_reclaim_acquire+0xd0/0xf0<br /> dma_resv_lockdep+0x224/0x348<br /> do_one_initcall+0x84/0x5d0<br /> do_initcalls+0x194/0x1d8<br /> kernel_init_freeable+0x128/0x180<br /> kernel_init+0x2c/0x160<br /> ret_from_fork+0x10/0x20<br /> <br /> -&gt; #1 (reservation_ww_class_mutex){+.+.}-{4:4}:<br /> __lock_acquire+0x4d0/0xad0<br /> lock_acquire.part.0+0xc4/0x248<br /> lock_acquire+0x8c/0x248<br /> dma_resv_lockdep+0x1a8/0x348<br /> do_one_initcall+0x84/0x5d0<br /> do_initcalls+0x194/0x1d8<br /> kernel_init_freeable+0x128/0x180<br /> kernel_init+0x2c/0x160<br /> ret_from_fork+0x10/0x20<br /> <br /> -&gt; #0 (reservation_ww_class_acquire){+.+.}-{0:0}:<br /> check_prev_add+0x114/0x790<br /> validate_chain+0x594/0x6f0<br /> __lock_acquire+0x4d0/0xad0<br /> lock_acquire.part.0+0xc4/0x248<br /> lock_acquire+0x8c/0x248<br /> drm_gem_lru_scan+0x1ac/0x440<br /> msm_gem_shrinker_scan+0x17c/0x400 [msm]<br /> do_shrink_slab+0x150/0x4a0<br /> shrink_slab+0x144/0x460<br /> shrink_one+0x9c/0x1b0<br /> shrink_many+0x27c/0x5c0<br /> shrink_node+0x344/0x550<br /> balance_pgdat+0x2c0/0x988<br /> kswapd+0x11c/0x318<br /> kthread+0x10c/0x128<br /> ret_from_fork+0x10/0x20<br /> <br /> other info that might help us debug this:<br /> Chain exists of:<br /> reservation_ww_class_acquire --&gt; reservation_ww_class_mutex --&gt; fs_reclaim<br /> Possible unsafe locking scenario:<br /> CPU0 CPU1<br /> ---- ----<br /> lock(fs_reclaim);<br /> lock(reservation_ww_class_mutex);<br /> lock(fs_reclaim);<br /> lock(reservation_ww_class_acquire);<br /> <br /> *** DEADLOCK ***<br /> 1 lock held by kswapd0/82:<br /> #0: ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988<br /> <br /> stack backtrace:<br /> CPU: 4 UID: 0 PID: 82 Comm: kswapd0 Tainted: G W 7.0.0-debug+ #43 PREEMPT(full)<br /> Tainted: [W]=WARN<br /> Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET94W (1.66 ) 09/15/2025<br /> Call trace:<br /> show_stack+0x20/0x40 (C)<br /> dump_stack_lvl+0x9c/0xd0<br /> dump_stack+0x18/0x30<br /> print_circular_bug+0x114/0x120<br /> check_noncircular+0x178/0x198<br /> check_prev_add+0x114/0x790<br /> validate_chain+0x594/0x6f0<br /> __lock_acquire+0x4d0/0xad0<br /> lock_acquire.part.0+0xc4/0x248<br /> lock_acquire+0x8c/0x248<br /> drm_gem_lru_scan+0x1ac/0x440<br /> msm_gem_shrinker_scan+0x17c/0x400 [msm]<br /> do_shrink_slab+0x150/0x4a0<br /> shrink_slab+0x144/0x460<br /> shrink_one+0x9c/0x1b0<br /> shrink_many+0x27c/0x5c0<br /> shrink_node+0x344/0x550<br /> balance_pgdat+0x2c0/0x988<br /> kswapd+0x11c/0x318<br /> kthread+0x10c/0x128<br /> ret_from_fork+0x10/0x20<br /> <br /> kswapd0 holding fs_reclaim calls the MSM shrinker, which calls<br /> dma_resv_lock. This in turn acquires fs_reclaim.<br /> <br /> Fix this deadlock by using dma_resv_trylock() instead, dropping the<br /> subsequently unused passed wait-wound lock &amp;#39;ticket&amp;#39;.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/723564/<br /> [rob: fixup compile errors, replace lockdep splat with somethin<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fwctl: pds: Validate RPC input size before parsing<br /> <br /> The fwctl core allocates the device-specific RPC input buffer with<br /> fwctl_rpc.in_len and passes that buffer to the driver callback.<br /> <br /> pdsfc_fw_rpc() casts the buffer to struct fwctl_rpc_pds and then calls<br /> pdsfc_validate_rpc(), which reads fields from that structure before<br /> checking that the input buffer is large enough to contain it. A short<br /> in_len can make pds_fwctl read beyond the allocation.<br /> <br /> Reject pds RPC buffers that are smaller than struct fwctl_rpc_pds before<br /> parsing any pds-specific fields.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tp_meter: fix tp_vars reference leak in receiver shutdown<br /> <br /> The receiver shutdown timer handler, batadv_tp_receiver_shutdown(), is<br /> responsible for releasing the tp_vars reference it holds. However, the<br /> existing logic for coordinating this release with batadv_tp_stop_all() was<br /> flawed.<br /> <br /> timer_shutdown_sync() guarantees the timer will not fire again after it<br /> returns, but it returns non-zero only when the timer was pending at the<br /> time of the call. If the timer had already expired (and<br /> batadv_tp_stop_all() would unsucessfully try to rearm itself),<br /> batadv_tp_stop_all() skips its batadv_tp_vars_put(), and<br /> batadv_tp_receiver_shutdown() fails to put its own reference as well.<br /> <br /> Fix this by introducing a new atomic variable receiving that is set to 1<br /> when the receiver is initialized and cleared atomically with atomic_xchg()<br /> by whichever side claims it first. Only the side that observes the<br /> transition from 1 to 0 is responsible for releasing the tp_vars timer<br /> reference, eliminating the uncertainty.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tp_meter: directly shut down timer on cleanup<br /> <br /> batadv_tp_sender_cleanup() was calling timer_delete_sync() followed by<br /> timer_delete() to guard against the timer handler re-arming itself between<br /> the two calls. This double-deletion hack relied on the sending status being<br /> set to 0 to suppress re-arming.<br /> <br /> Replace both calls with a single timer_shutdown_sync(). This function both<br /> waits for any running timer callback to complete (like timer_delete_sync())<br /> and permanently disarms the timer so it cannot be re-armed afterwards,<br /> making re-arming prevention unconditional and self-documenting.<br /> <br /> The re-arming property is also required because otherwise:<br /> <br /> 1. context 0 (batadv_tp_recv_ack()) checks in<br /> batadv_tp_reset_sender_timer() if sending is still 1 -&gt; it is<br /> 2. context 1 changes in batadv_tp_sender_shutdown() sending to 0 and in<br /> this process forces the kthread to stop timer in<br /> batadv_tp_sender_cleanup()<br /> 3. context 0 continues in batadv_tp_reset_sender_timer() and rearms the<br /> timer -&gt; but the reference for it is already gone

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface<br /> <br /> Without rtnl_lock held, a hardif might be retrieved as primary interface of<br /> a meshif, but then (while operating on this interface) getting decoupled<br /> from the mesh interface. In this case, the meshif still exists but the<br /> pointer from the primary hardif to the meshif is set to NULL.<br /> <br /> The mesh_iface must be checked first to be non-NULL before continuing to<br /> send an ARP request using meshif.