Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/sync: Cleanup partially initialized sync on parse failure<br /> <br /> xe_sync_entry_parse() can allocate references (syncobj, fence, chain fence,<br /> or user fence) before hitting a later failure path. Several of those paths<br /> returned directly, leaving partially initialized state and leaking refs.<br /> <br /> Route these error paths through a common free_sync label and call<br /> xe_sync_entry_cleanup(sync) before returning the error.<br /> <br /> (cherry picked from commit f939bdd9207a5d1fc55cced5459858480686ce22)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in smb_lazy_parent_lease_break_close()<br /> <br /> opinfo pointer obtained via rcu_dereference(fp-&gt;f_opinfo) is being<br /> accessed after rcu_read_unlock() has been called. This creates a<br /> race condition where the memory could be freed by a concurrent<br /> writer between the unlock and the subsequent pointer dereferences<br /> (opinfo-&gt;is_lease, etc.), leading to a use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read<br /> <br /> The q54sj108a2_debugfs_read function suffers from a stack buffer overflow<br /> due to incorrect arguments passed to bin2hex(). The function currently<br /> passes &amp;#39;data&amp;#39; as the destination and &amp;#39;data_char&amp;#39; as the source.<br /> <br /> Because bin2hex() converts each input byte into two hex characters, a<br /> 32-byte block read results in 64 bytes of output. Since &amp;#39;data&amp;#39; is only<br /> 34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the end<br /> of the buffer onto the stack.<br /> <br /> Additionally, the arguments were swapped: it was reading from the<br /> zero-initialized &amp;#39;data_char&amp;#39; and writing to &amp;#39;data&amp;#39;, resulting in<br /> all-zero output regardless of the actual I2C read.<br /> <br /> Fix this by:<br /> 1. Expanding &amp;#39;data_char&amp;#39; to 66 bytes to safely hold the hex output.<br /> 2. Correcting the bin2hex() argument order and using the actual read count.<br /> 3. Using a pointer to select the correct output buffer for the final<br /> simple_read_from_buffer call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nouveau/dpcd: return EBUSY for aux xfer if the device is asleep<br /> <br /> If we have runtime suspended, and userspace wants to use /dev/drm_dp_*<br /> then just tell it the device is busy instead of crashing in the GSP<br /> code.<br /> <br /> WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]<br /> CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy)<br /> Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024<br /> RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]<br /> <br /> This is a simple fix to get backported. We should probably engineer a<br /> proper power domain solution to wake up devices and keep them awake<br /> while fw updates are happening.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: Avoid double-rtnl_lock ELP metric worker<br /> <br /> batadv_v_elp_get_throughput() might be called when the RTNL lock is already<br /> held. This could be problematic when the work queue item is cancelled via<br /> cancel_delayed_work_sync() in batadv_v_elp_iface_disable(). In this case,<br /> an rtnl_lock() would cause a deadlock.<br /> <br /> To avoid this, rtnl_trylock() was used in this function to skip the<br /> retrieval of the ethtool information in case the RTNL lock was already<br /> held.<br /> <br /> But for cfg80211 interfaces, batadv_get_real_netdev() was called - which<br /> also uses rtnl_lock(). The approach for __ethtool_get_link_ksettings() must<br /> also be used instead and the lockless version __batadv_get_real_netdev()<br /> has to be called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tcp-md5: Fix MAC comparison to be constant-time<br /> <br /> To prevent timing attacks, MACs need to be compared in constant<br /> time. Use the appropriate helper function for this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tcp-ao: Fix MAC comparison to be constant-time<br /> <br /> To prevent timing attacks, MACs need to be compared in constant<br /> time. Use the appropriate helper function for this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Fix rcu_tasks stall in threaded busypoll<br /> <br /> I was debugging a NIC driver when I noticed that when I enable<br /> threaded busypoll, bpftrace hangs when starting up. dmesg showed:<br /> <br /> rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 10658 jiffies old.<br /> rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 40793 jiffies old.<br /> rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 131273 jiffies old.<br /> rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 402058 jiffies old.<br /> INFO: rcu_tasks detected stalls on tasks:<br /> 00000000769f52cd: .N nvcsw: 2/2 holdout: 1 idle_cpu: -1/64<br /> task:napi/eth2-8265 state:R running task stack:0 pid:48300 tgid:48300 ppid:2 task_flags:0x208040 flags:0x00004000<br /> Call Trace:<br /> <br /> ? napi_threaded_poll_loop+0x27c/0x2c0<br /> ? __pfx_napi_threaded_poll+0x10/0x10<br /> ? napi_threaded_poll+0x26/0x80<br /> ? kthread+0xfa/0x240<br /> ? __pfx_kthread+0x10/0x10<br /> ? ret_from_fork+0x31/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ? ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> The cause is that in threaded busypoll, the main loop is in<br /> napi_threaded_poll rather than napi_threaded_poll_loop, where the<br /> latter rarely iterates more than once within its loop. For<br /> rcu_softirq_qs_periodic inside napi_threaded_poll_loop to report its<br /> qs state, the last_qs must be 100ms behind, and this can&amp;#39;t happen<br /> because napi_threaded_poll_loop rarely iterates in threaded busypoll,<br /> and each time napi_threaded_poll_loop is called last_qs is reset to<br /> latest jiffies.<br /> <br /> This patch changes so that in threaded busypoll, last_qs is saved<br /> in the outer napi_threaded_poll, and whether busy_poll_last_qs<br /> is NULL indicates whether napi_threaded_poll_loop is called for<br /> busypoll. This way last_qs would not reset to latest jiffies on<br /> each invocation of napi_threaded_poll_loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie<br /> <br /> The current code checks &amp;#39;i + 5

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix use-after-free race in VM acquire<br /> <br /> Replace non-atomic vm-&gt;process_info assignment with cmpxchg()<br /> to prevent race when parent/child processes sharing a drm_file<br /> both try to acquire the same VM after fork().<br /> <br /> (cherry picked from commit c7c573275ec20db05be769288a3e3bb2250ec618)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: Shuffle the tx ring before enabling tx<br /> <br /> Quanyang observed that when using an NFS rootfs on an AMD ZynqMp board,<br /> the rootfs may take an extended time to recover after a suspend.<br /> Upon investigation, it was determined that the issue originates from a<br /> problem in the macb driver.<br /> <br /> According to the Zynq UltraScale TRM [1], when transmit is disabled,<br /> the transmit buffer queue pointer resets to point to the address<br /> specified by the transmit buffer queue base address register.<br /> <br /> In the current implementation, the code merely resets `queue-&gt;tx_head`<br /> and `queue-&gt;tx_tail` to &amp;#39;0&amp;#39;. This approach presents several issues:<br /> <br /> - Packets already queued in the tx ring are silently lost,<br /> leading to memory leaks since the associated skbs cannot be released.<br /> <br /> - Concurrent write access to `queue-&gt;tx_head` and `queue-&gt;tx_tail` may<br /> occur from `macb_tx_poll()` or `macb_start_xmit()` when these values<br /> are reset to &amp;#39;0&amp;#39;.<br /> <br /> - The transmission may become stuck on a packet that has already been sent<br /> out, with its &amp;#39;TX_USED&amp;#39; bit set, but has not yet been processed. However,<br /> due to the manipulation of &amp;#39;queue-&gt;tx_head&amp;#39; and &amp;#39;queue-&gt;tx_tail&amp;#39;,<br /> `macb_tx_poll()` incorrectly assumes there are no packets to handle<br /> because `queue-&gt;tx_head == queue-&gt;tx_tail`. This issue is only resolved<br /> when a new packet is placed at this position. This is the root cause of<br /> the prolonged recovery time observed for the NFS root filesystem.<br /> <br /> To resolve this issue, shuffle the tx ring and tx skb array so that<br /> the first unsent packet is positioned at the start of the tx ring.<br /> Additionally, ensure that updates to `queue-&gt;tx_head` and<br /> `queue-&gt;tx_tail` are properly protected with the appropriate lock.<br /> <br /> [1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: microchip: Fix error path in PTP IRQ setup<br /> <br /> If request_threaded_irq() fails during the PTP message IRQ setup, the<br /> newly created IRQ mapping is never disposed. Indeed, the<br /> ksz_ptp_irq_setup()&amp;#39;s error path only frees the mappings that were<br /> successfully set up.<br /> <br /> Dispose the newly created mapping if the associated<br /> request_threaded_irq() fails at setup.