Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: close accepted socket when per-IP limit rejects connection<br /> <br /> When the per-IP connection limit is exceeded in ksmbd_kthread_fn(),<br /> the code sets ret = -EAGAIN and continues the accept loop without<br /> closing the just-accepted socket. That leaks one socket per rejected<br /> attempt from a single IP and enables a trivial remote DoS.<br /> <br /> Release client_sk before continuing.<br /> <br /> This bug was found with ZeroPath.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> posix-timers: Plug potential memory leak in do_timer_create()<br /> <br /> When posix timer creation is set to allocate a given timer ID and the<br /> access to the user space value faults, the function terminates without<br /> freeing the already allocated posix timer structure.<br /> <br /> Move the allocation after the user space access to cure that.<br /> <br /> [ tglx: Massaged change log ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/cmd_net: fix wrong argument types for skb_queue_splice()<br /> <br /> If timestamp retriving needs to be retried and the local list of<br /> SKB&amp;#39;s already has entries, then it&amp;#39;s spliced back into the socket<br /> queue. However, the arguments for the splice helper are transposed,<br /> causing exactly the wrong direction of splicing into the on-stack<br /> list. Fix that up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot<br /> <br /> nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a<br /> kmemleak warning.<br /> <br /> Make sure this data is deallocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)<br /> <br /> According to UFS specifications, the power-off sequence for a UFS device<br /> includes:<br /> <br /> - Sending an SSU command with Power_Condition=3 and await a response.<br /> <br /> - Asserting RST_N low.<br /> <br /> - Turning off REF_CLK.<br /> <br /> - Turning off VCC.<br /> <br /> - Turning off VCCQ/VCCQ2.<br /> <br /> As part of ufs shutdown, after the SSU command completion, asserting<br /> hardware reset (HWRST) triggers the device firmware to wake up and<br /> execute its reset routine. This routine initializes hardware blocks and<br /> takes a few milliseconds to complete. During this time, the ICCQ draws a<br /> large current.<br /> <br /> This large ICCQ current may cause issues for the regulator which is<br /> supplying power to UFS, because the turn off request from UFS driver to<br /> the regulator framework will be immediately followed by low power<br /> mode(LPM) request by regulator framework. This is done by framework<br /> because UFS which is the only client is requesting for disable. So if<br /> the rail is still in the process of shutting down while ICCQ exceeds LPM<br /> current thresholds, and LPM mode is activated in hardware during this<br /> state, it may trigger an overcurrent protection (OCP) fault in the<br /> regulator.<br /> <br /> To prevent this, a 10ms delay is added after asserting HWRST. This<br /> allows the reset operation to complete while power rails remain active<br /> and in high-power mode.<br /> <br /> Currently there is no way for Host to query whether the reset is<br /> completed or not and hence this the delay is based on experiments with<br /> Qualcomm UFS controllers across multiple UFS vendors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtdchar: fix integer overflow in read/write ioctls<br /> <br /> The "req.start" and "req.len" variables are u64 values that come from the<br /> user at the start of the function. We mask away the high 32 bits of<br /> "req.len" so that&amp;#39;s capped at U32_MAX but the "req.start" variable can go<br /> up to U64_MAX which means that the addition can still integer overflow.<br /> <br /> Use check_add_overflow() to fix this bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: cadence: fix DMA device NULL pointer dereference<br /> <br /> The DMA device pointer `dma_dev` was being dereferenced before ensuring<br /> that `cdns_ctrl-&gt;dmac` is properly initialized.<br /> <br /> Move the assignment of `dma_dev` after successfully acquiring the DMA<br /> channel to ensure the pointer is valid before use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()<br /> <br /> If the allocation of tl_hba-&gt;sh fails in tcm_loop_driver_probe() and we<br /> attempt to dereference it in tcm_loop_tpg_address_show() we will get a<br /> segfault, see below for an example. So, check tl_hba-&gt;sh before<br /> dereferencing it.<br /> <br /> Unable to allocate struct scsi_host<br /> BUG: kernel NULL pointer dereference, address: 0000000000000194<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1<br /> Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024<br /> RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]<br /> ...<br /> Call Trace:<br /> <br /> configfs_read_iter+0x12d/0x1d0 [configfs]<br /> vfs_read+0x1b5/0x300<br /> ksys_read+0x6f/0xf0<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix gpu page fault after hibernation on PF passthrough<br /> <br /> On PF passthrough environment, after hibernate and then resume, coralgemm<br /> will cause gpu page fault.<br /> <br /> Mode1 reset happens during hibernate, but partition mode is not restored<br /> on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right<br /> after resume. When CP access the MQD BO, wrong stride size is used,<br /> this will cause out of bound access on the MQD BO, resulting page fault.<br /> <br /> The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called<br /> when resume from a hibernation.<br /> KFD resume is called separately during a reset recovery or resume from<br /> suspend sequence. Hence it&amp;#39;s not required to be called as part of<br /> partition switch.<br /> <br /> (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/mempool: fix poisoning order&gt;0 pages with HIGHMEM<br /> <br /> The kernel test has reported:<br /> <br /> BUG: unable to handle page fault for address: fffba000<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> *pde = 03171067 *pte = 00000000<br /> Oops: Oops: 0002 [#1]<br /> CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca<br /> Tainted: [T]=RANDSTRUCT<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17)<br /> Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56<br /> EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b<br /> ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8<br /> DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287<br /> CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690<br /> Call Trace:<br /> poison_element (mm/mempool.c:83 mm/mempool.c:102)<br /> mempool_init_node (mm/mempool.c:142 mm/mempool.c:226)<br /> mempool_init_noprof (mm/mempool.c:250 (discriminator 1))<br /> ? mempool_alloc_pages (mm/mempool.c:640)<br /> bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8))<br /> ? mempool_alloc_pages (mm/mempool.c:640)<br /> do_one_initcall (init/main.c:1283)<br /> <br /> Christoph found out this is due to the poisoning code not dealing<br /> properly with CONFIG_HIGHMEM because only the first page is mapped but<br /> then the whole potentially high-order page is accessed.<br /> <br /> We could give up on HIGHMEM here, but it&amp;#39;s straightforward to fix this<br /> with a loop that&amp;#39;s mapping, poisoning or checking and unmapping<br /> individual pages.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> veth: more robust handing of race to avoid txq getting stuck<br /> <br /> Commit dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to<br /> reduce TX drops") introduced a race condition that can lead to a permanently<br /> stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra<br /> Max).<br /> <br /> The race occurs in veth_xmit(). The producer observes a full ptr_ring and<br /> stops the queue (netif_tx_stop_queue()). The subsequent conditional logic,<br /> intended to re-wake the queue if the consumer had just emptied it (if<br /> (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a<br /> "lost wakeup" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and<br /> traffic halts.<br /> <br /> This failure is caused by an incorrect use of the __ptr_ring_empty() API<br /> from the producer side. As noted in kernel comments, this check is not<br /> guaranteed to be correct if a consumer is operating on another CPU. The<br /> empty test is based on ptr_ring-&gt;consumer_head, making it reliable only for<br /> the consumer. Using this check from the producer side is fundamentally racy.<br /> <br /> This patch fixes the race by adopting the more robust logic from an earlier<br /> version V4 of the patchset, which always flushed the peer:<br /> <br /> (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier<br /> are removed. Instead, after stopping the queue, we unconditionally call<br /> __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled,<br /> making it solely responsible for re-waking the TXQ.<br /> This handles the race where veth_poll() consumes all packets and completes<br /> NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue.<br /> The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule<br /> NAPI.<br /> <br /> (2) On the consumer side, the logic for waking the peer TXQ is moved out of<br /> veth_xdp_rcv() and placed at the end of the veth_poll() function. This<br /> placement is part of fixing the race, as the netif_tx_queue_stopped() check<br /> must occur after rx_notify_masked is potentially set to false during NAPI<br /> completion.<br /> This handles the race where veth_poll() consumes all packets, but haven&amp;#39;t<br /> finished (rx_notify_masked is still true). The producer veth_xmit() stops the<br /> TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning<br /> not starting NAPI. Then veth_poll() change rx_notify_masked to false and<br /> stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake<br /> it up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/tegra: Add call to put_pid()<br /> <br /> Add a call to put_pid() corresponding to get_task_pid().<br /> host1x_memory_context_alloc() does not take ownership of the PID so we<br /> need to free it here to avoid leaking.<br /> <br /> [mperttunen@nvidia.com: reword commit message]