Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/rt: Skip currently executing CPU in rto_next_cpu()<br /> <br /> CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound<br /> RT task, and a CFS task stuck in kernel space. When other CPUs switch from<br /> RT to non-RT tasks, RT load balancing (LB) is triggered; with<br /> HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution<br /> of rto_push_irq_work_func. During push_rt_task on CPU0,<br /> if next_task-&gt;prio donor-&gt;prio, resched_curr() sets NEED_RESCHED<br /> and after the push operation completes, CPU0 calls rto_next_cpu().<br /> Since only CPU0 is overloaded in this scenario, rto_next_cpu() should<br /> ideally return -1 (no further IPI needed).<br /> <br /> However, multiple CPUs invoking tell_cpu_to_push() during LB increments<br /> rd-&gt;rto_loop_next. Even when rd-&gt;rto_cpu is set to -1, the mismatch between<br /> rd-&gt;rto_loop and rd-&gt;rto_loop_next forces rto_next_cpu() to restart its<br /> search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory<br /> &amp;&amp; rt_nr_total &gt; 1), it gets reselected, causing CPU0 to queue irq_work to<br /> itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and<br /> other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,<br /> which triggers a CPU hardlockup due to continuous self-interrupts.<br /> <br /> The trigging scenario is as follows:<br /> <br /> cpu0 cpu1 cpu2<br /> pull_rt_task<br /> tell_cpu_to_push<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: tcp - don&amp;#39;t deref NULL sk_socket member after tcp_close()<br /> <br /> When deleting a peer in case of keepalive expiration, the peer is<br /> removed from the OpenVPN hashtable and is temporary inserted in a<br /> "release list" for further processing.<br /> <br /> This happens in:<br /> ovpn_peer_keepalive_work()<br /> unlock_ovpn(release_list)<br /> <br /> This processing includes detaching from the socket being used to<br /> talk to this peer, by restoring its original proto and socket<br /> ops/callbacks.<br /> <br /> In case of TCP it may happen that, while the peer is sitting in<br /> the release list, userspace decides to close the socket.<br /> This will result in a concurrent execution of:<br /> <br /> tcp_close(sk)<br /> __tcp_close(sk)<br /> sock_orphan(sk)<br /> sk_set_socket(sk, NULL)<br /> <br /> The last function call will set sk-&gt;sk_socket to NULL.<br /> <br /> When the releasing routine is resumed, ovpn_tcp_socket_detach()<br /> will attempt to dereference sk-&gt;sk_socket to restore its original<br /> ops member. This operation will crash due to sk-&gt;sk_socket being NULL.<br /> <br /> Fix this race condition by testing-and-accessing<br /> sk-&gt;sk_socket atomically under sk-&gt;sk_callback_lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: do not keep dest_dst if dev is going down<br /> <br /> There is race between the netdev notifier ip_vs_dst_event()<br /> and the code that caches dst with dev that is going down.<br /> As the FIB can be notified for the closed device after our<br /> handler finishes, it is possible valid route to be returned<br /> and cached resuling in a leaked dev reference until the dest<br /> is not removed.<br /> <br /> To prevent new dest_dst to be attached to dest just after the<br /> handler dropped the old one, add a netif_running() check<br /> to make sure the notifier handler is not currently running<br /> for device that is closing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: sbs-battery: Fix use-after-free in power_supply_changed()<br /> <br /> Using the `devm_` variant for requesting IRQ _before_ the `devm_`<br /> variant for allocating/registering the `power_supply` handle, means that<br /> the `power_supply` handle will be deallocated/unregistered _before_ the<br /> interrupt handler (since `devm_` naturally deallocates in reverse<br /> allocation order). This means that during removal, there is a race<br /> condition where an interrupt can fire just _after_ the `power_supply`<br /> handle has been freed, *but* just _before_ the corresponding<br /> unregistration of the IRQ handler has run.<br /> <br /> This will lead to the IRQ handler calling `power_supply_changed()` with<br /> a freed `power_supply` handle. Which usually crashes the system or<br /> otherwise silently corrupts the memory...<br /> <br /> Note that there is a similar situation which can also happen during<br /> `probe()`; the possibility of an interrupt firing _before_ registering<br /> the `power_supply` handle. This would then lead to the nasty situation<br /> of using the `power_supply` handle *uninitialized* in<br /> `power_supply_changed()`.<br /> <br /> Fix this racy use-after-free by making sure the IRQ is requested _after_<br /> the registration of the `power_supply` handle. Keep the old behavior of<br /> just printing a warning in case of any failures during the IRQ request<br /> and finishing the probe successfully.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fat: avoid parent link count underflow in rmdir<br /> <br /> Corrupted FAT images can leave a directory inode with an incorrect<br /> i_nlink (e.g. 2 even though subdirectories exist). rmdir then<br /> unconditionally calls drop_nlink(dir) and can drive i_nlink to 0,<br /> triggering the WARN_ON in drop_nlink().<br /> <br /> Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the<br /> parent link count when it is at least 3, otherwise report a filesystem<br /> error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: don&amp;#39;t cache extent during splitting extent<br /> <br /> Caching extents during the splitting process is risky, as it may result<br /> in stale extents remaining in the status tree. Moreover, in most cases,<br /> the corresponding extent block entries are likely already cached before<br /> the split happens, making caching here not particularly useful.<br /> <br /> Assume we have an unwritten extent, and then DIO writes the first half.<br /> <br /> [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent<br /> [UUUUUUUUUUUUUUUU] extent status tree<br /> || ----&gt; dio write this range<br /> <br /> First, when ext4_split_extent_at() splits this extent, it truncates the<br /> existing extent and then inserts a new one. During this process, this<br /> extent status entry may be shrunk, and calls to ext4_find_extent() and<br /> ext4_cache_extents() may occur, which could potentially insert the<br /> truncated range as a hole into the extent status tree. After the split<br /> is completed, this hole is not replaced with the correct status.<br /> <br /> [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent<br /> [UUUUUUU|HHHHHHHH] extent status tree H: hole<br /> <br /> Then, the outer calling functions will not correct this remaining hole<br /> extent either. Finally, if we perform a delayed buffer write on this<br /> latter part, it will re-insert the delayed extent and cause an error in<br /> space accounting.<br /> <br /> In adition, if the unwritten extent cache is not shrunk during the<br /> splitting, ext4_cache_extents() also conflicts with existing extents<br /> when caching extents. In the future, we will add checks when caching<br /> extents, which will trigger a warning. Therefore, Do not cache extents<br /> that are being split.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: fix role switching during resume<br /> <br /> If the role change while we are suspended, the cdns3 driver switches to the<br /> new mode during resume. However, switching to host mode in this context<br /> causes a NULL pointer dereference.<br /> <br /> The host role&amp;#39;s start() operation registers a xhci-hcd device, but its<br /> probe is deferred while we are in the resume path. The host role&amp;#39;s resume()<br /> operation assumes the xhci-hcd device is already probed, which is not the<br /> case, leading to the dereference. Since the start() operation of the new<br /> role is already called, the resume operation can be skipped.<br /> <br /> So skip the resume operation for the new role if a role switch occurs<br /> during resume. Once the resume sequence is complete, the xhci-hcd device<br /> can be probed in case of host mode.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208<br /> Mem abort info:<br /> ...<br /> Data abort info:<br /> ...<br /> [0000000000000208] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted<br /> 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT<br /> Hardware name: Texas Instruments J7200 EVM (DT)<br /> pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : usb_hcd_is_primary_hcd+0x0/0x1c<br /> lr : cdns_host_resume+0x24/0x5c<br /> ...<br /> Call trace:<br /> usb_hcd_is_primary_hcd+0x0/0x1c (P)<br /> cdns_resume+0x6c/0xbc<br /> cdns3_controller_resume.isra.0+0xe8/0x17c<br /> cdns3_plat_resume+0x18/0x24<br /> platform_pm_resume+0x2c/0x68<br /> dpm_run_callback+0x90/0x248<br /> device_resume+0x100/0x24c<br /> dpm_resume+0x190/0x2ec<br /> dpm_resume_end+0x18/0x34<br /> suspend_devices_and_enter+0x2b0/0xa44<br /> pm_suspend+0x16c/0x5fc<br /> state_store+0x80/0xec<br /> kobj_attr_store+0x18/0x2c<br /> sysfs_kf_write+0x7c/0x94<br /> kernfs_fop_write_iter+0x130/0x1dc<br /> vfs_write+0x240/0x370<br /> ksys_write+0x70/0x108<br /> __arm64_sys_write+0x1c/0x28<br /> invoke_syscall+0x48/0x10c<br /> el0_svc_common.constprop.0+0x40/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x34/0x108<br /> el0t_64_sync_handler+0xa0/0xe4<br /> el0t_64_sync+0x198/0x19c<br /> Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401)<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix race condition in QP timer handlers<br /> <br /> I encontered the following warning:<br /> WARNING: drivers/infiniband/sw/rxe/rxe_task.c:249 at rxe_sched_task+0x1c8/0x238 [rdma_rxe], CPU#0: swapper/0/0<br /> ...<br /> libsha1 [last unloaded: ip6_udp_tunnel]<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G C 6.19.0-rc5-64k-v8+ #37 PREEMPT<br /> Tainted: [C]=CRAP<br /> Hardware name: Raspberry Pi 4 Model B Rev 1.2<br /> Call trace:<br /> rxe_sched_task+0x1c8/0x238 [rdma_rxe] (P)<br /> retransmit_timer+0x130/0x188 [rdma_rxe]<br /> call_timer_fn+0x68/0x4d0<br /> __run_timers+0x630/0x888<br /> ...<br /> WARNING: drivers/infiniband/sw/rxe/rxe_task.c:38 at rxe_sched_task+0x1c0/0x238 [rdma_rxe], CPU#0: swapper/0/0<br /> ...<br /> WARNING: drivers/infiniband/sw/rxe/rxe_task.c:111 at do_work+0x488/0x5c8 [rdma_rxe], CPU#3: kworker/u17:4/93400<br /> ...<br /> refcount_t: underflow; use-after-free.<br /> WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x138/0x1a0, CPU#3: kworker/u17:4/93400<br /> <br /> The issue is caused by a race condition between retransmit_timer() and<br /> rxe_destroy_qp, leading to the Queue Pair&amp;#39;s (QP) reference count dropping<br /> to zero during timer handler execution.<br /> <br /> It seems this warning is harmless because rxe_qp_do_cleanup() will flush<br /> all pending timers and requests.<br /> <br /> Example of flow causing the issue:<br /> <br /> CPU0 CPU1<br /> retransmit_timer() {<br /> spin_lock_irqsave<br /> rxe_destroy_qp()<br /> __rxe_cleanup()<br /> __rxe_put() // qp-&gt;ref_count decrease to 0<br /> rxe_qp_do_cleanup() {<br /> if (qp-&gt;valid) {<br /> rxe_sched_task() {<br /> WARN_ON(rxe_read(task-&gt;qp) valid = 0<br /> spin_unlock_irqrestore<br /> }<br /> <br /> Ensure the QP&amp;#39;s reference count is maintained and its validity is checked<br /> within the timer callbacks by adding calls to rxe_get(qp) and corresponding<br /> rxe_put(qp) after use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: Drop __initconst from gates<br /> <br /> Since commit 8ceff24a754a ("clk: mediatek: clk-gate: Refactor<br /> mtk_clk_register_gate to use mtk_gate struct") the mtk_gate structs<br /> are no longer just used for initialization/registration, but also at<br /> runtime. So drop __initconst annotations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Fix memory leak in amdxdna_ubuf_map<br /> <br /> The amdxdna_ubuf_map() function allocates memory for sg and<br /> internal sg table structures, but it fails to free them if subsequent<br /> operations (sg_alloc_table_from_pages or dma_map_sgtable) fail.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix deadlocks between devlink and netdev instance locks<br /> <br /> In the mentioned "Fixes" commit, various work tasks triggering devlink<br /> health reporter recovery were switched to use netdev_trylock to protect<br /> against concurrent tear down of the channels being recovered. But this<br /> had the side effect of introducing potential deadlocks because of<br /> incorrect lock ordering.<br /> <br /> The correct lock order is described by the init flow:<br /> probe_one -&gt; mlx5_init_one (acquires devlink lock)<br /> -&gt; mlx5_init_one_devl_locked -&gt; mlx5_register_device<br /> -&gt; mlx5_rescan_drivers_locked -...-&gt; mlx5e_probe -&gt; _mlx5e_probe<br /> -&gt; register_netdev (acquires rtnl lock)<br /> -&gt; register_netdevice (acquires netdev lock)<br /> =&gt; devlink lock -&gt; rtnl lock -&gt; netdev lock.<br /> <br /> But in the current recovery flow, the order is wrong:<br /> mlx5e_tx_err_cqe_work (acquires netdev lock)<br /> -&gt; mlx5e_reporter_tx_err_cqe -&gt; mlx5e_health_report<br /> -&gt; devlink_health_report (acquires devlink lock =&gt; boom!)<br /> -&gt; devlink_health_reporter_recover<br /> -&gt; mlx5e_tx_reporter_recover -&gt; mlx5e_tx_reporter_recover_from_ctx<br /> -&gt; mlx5e_tx_reporter_err_cqe_recover<br /> <br /> The same pattern exists in:<br /> mlx5e_reporter_rx_timeout<br /> mlx5e_reporter_tx_ptpsq_unhealthy<br /> mlx5e_reporter_tx_timeout<br /> <br /> Fix these by moving the netdev_trylock calls from the work handlers<br /> lower in the call stack, in the respective recovery functions, where<br /> they are actually necessary.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: pf1550: Fix use-after-free in power_supply_changed()<br /> <br /> Using the `devm_` variant for requesting IRQ _before_ the `devm_`<br /> variant for allocating/registering the `power_supply` handle, means that<br /> the `power_supply` handle will be deallocated/unregistered _before_ the<br /> interrupt handler (since `devm_` naturally deallocates in reverse<br /> allocation order). This means that during removal, there is a race<br /> condition where an interrupt can fire just _after_ the `power_supply`<br /> handle has been freed, *but* just _before_ the corresponding<br /> unregistration of the IRQ handler has run.<br /> <br /> This will lead to the IRQ handler calling `power_supply_changed()` with<br /> a freed `power_supply` handle. Which usually crashes the system or<br /> otherwise silently corrupts the memory...<br /> <br /> Note that there is a similar situation which can also happen during<br /> `probe()`; the possibility of an interrupt firing _before_ registering<br /> the `power_supply` handle. This would then lead to the nasty situation<br /> of using the `power_supply` handle *uninitialized* in<br /> `power_supply_changed()`.<br /> <br /> Fix this racy use-after-free by making sure the IRQ is requested _after_<br /> the registration of the `power_supply` handle.