Vulnerabilidades

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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 /> ...

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix incomplete backport in cfids_invalidation_worker()<br /> <br /> The previous commit bdb596ceb4b7 ("smb: client: fix potential UAF in<br /> smb2_close_cached_fid()") was an incomplete backport and missed one<br /> kref_put() call in cfids_invalidation_worker() that should have been<br /> converted to close_cached_dir().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: Fix proto fallback detection with BPF<br /> <br /> The sockmap feature allows bpf syscall from userspace, or based<br /> on bpf sockops, replacing the sk_prot of sockets during protocol stack<br /> processing with sockmap&amp;#39;s custom read/write interfaces.<br /> &amp;#39;&amp;#39;&amp;#39;<br /> tcp_rcv_state_process()<br /> syn_recv_sock()/subflow_syn_recv_sock()<br /> tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)<br /> bpf_skops_established ops.<br /> <br /> This fix uses the more generic sk_family for the comparison instead.<br /> <br /> Additionally, this also prevents a WARNING from occurring:<br /> <br /> result from ./scripts/decode_stacktrace.sh:<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \<br /> (net/mptcp/protocol.c:4005)<br /> Modules linked in:<br /> ...<br /> <br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> do_accept (net/socket.c:1989)<br /> __sys_accept4 (net/socket.c:2028 net/socket.c:2057)<br /> __x64_sys_accept (net/socket.c:2067)<br /> x64_sys_call (arch/x86/entry/syscall_64.c:41)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> RIP: 0033:0x7f87ac92b83d<br /> <br /> ---[ end trace 0000000000000000 ]---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/plane: Fix create_in_format_blob() return value<br /> <br /> create_in_format_blob() is either supposed to return a valid<br /> pointer or an error, but never NULL. The caller will dereference<br /> the blob when it is not an error, and thus will oops if NULL<br /> returned. Return proper error values in the failure cases.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix memory leak in smb3_fs_context_parse_param error path<br /> <br /> Add proper cleanup of ctx-&gt;source and fc-&gt;source to the<br /> cifs_parse_mount_err error handler. This ensures that memory allocated<br /> for the source strings is correctly freed on all error paths, matching<br /> the cleanup already performed in the success path by<br /> smb3_cleanup_fs_context_contents().<br /> Pointers are also set to NULL after freeing to prevent potential<br /> double-free issues.<br /> <br /> This change fixes a memory leak originally detected by syzbot. The<br /> leak occurred when processing Opt_source mount options if an error<br /> happened after ctx-&gt;source and fc-&gt;source were successfully<br /> allocated but before the function completed.<br /> <br /> The specific leak sequence was:<br /> 1. ctx-&gt;source = smb3_fs_context_fullpath(ctx, &amp;#39;/&amp;#39;) allocates memory<br /> 2. fc-&gt;source = kstrdup(ctx-&gt;source, GFP_KERNEL) allocates more memory<br /> 3. A subsequent error jumps to cifs_parse_mount_err<br /> 4. The old error handler freed passwords but not the source strings,<br /> causing the memory to leak.<br /> <br /> This issue was not addressed by commit e8c73eb7db0a ("cifs: client:<br /> fix memory leak in smb3_fs_context_parse_param"), which only fixed<br /> leaks from repeated fsconfig() calls but not this error path.<br /> <br /> Patch updated with minor change suggested by kernel test robot