Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: mtk-star-emac: fix spinlock recursion issues on rx/tx poll<br /> <br /> Use spin_lock_irqsave and spin_unlock_irqrestore instead of spin_lock<br /> and spin_unlock in mtk_star_emac driver to avoid spinlock recursion<br /> occurrence that can happen when enabling the DMA interrupts again in<br /> rx/tx poll.<br /> <br /> ```<br /> BUG: spinlock recursion on CPU#0, swapper/0/0<br /> lock: 0xffff00000db9cf20, .magic: dead4ead, .owner: swapper/0/0,<br /> .owner_cpu: 0<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted<br /> 6.15.0-rc2-next-20250417-00001-gf6a27738686c-dirty #28 PREEMPT<br /> Hardware name: MediaTek MT8365 Open Platform EVK (DT)<br /> Call trace:<br /> show_stack+0x18/0x24 (C)<br /> dump_stack_lvl+0x60/0x80<br /> dump_stack+0x18/0x24<br /> spin_dump+0x78/0x88<br /> do_raw_spin_lock+0x11c/0x120<br /> _raw_spin_lock+0x20/0x2c<br /> mtk_star_handle_irq+0xc0/0x22c [mtk_star_emac]<br /> __handle_irq_event_percpu+0x48/0x140<br /> handle_irq_event+0x4c/0xb0<br /> handle_fasteoi_irq+0xa0/0x1bc<br /> handle_irq_desc+0x34/0x58<br /> generic_handle_domain_irq+0x1c/0x28<br /> gic_handle_irq+0x4c/0x120<br /> do_interrupt_handler+0x50/0x84<br /> el1_interrupt+0x34/0x68<br /> el1h_64_irq_handler+0x18/0x24<br /> el1h_64_irq+0x6c/0x70<br /> regmap_mmio_read32le+0xc/0x20 (P)<br /> _regmap_bus_reg_read+0x6c/0xac<br /> _regmap_read+0x60/0xdc<br /> regmap_read+0x4c/0x80<br /> mtk_star_rx_poll+0x2f4/0x39c [mtk_star_emac]<br /> __napi_poll+0x38/0x188<br /> net_rx_action+0x164/0x2c0<br /> handle_softirqs+0x100/0x244<br /> __do_softirq+0x14/0x20<br /> ____do_softirq+0x10/0x20<br /> call_on_irq_stack+0x24/0x64<br /> do_softirq_own_stack+0x1c/0x40<br /> __irq_exit_rcu+0xd4/0x10c<br /> irq_exit_rcu+0x10/0x1c<br /> el1_interrupt+0x38/0x68<br /> el1h_64_irq_handler+0x18/0x24<br /> el1h_64_irq+0x6c/0x70<br /> cpuidle_enter_state+0xac/0x320 (P)<br /> cpuidle_enter+0x38/0x50<br /> do_idle+0x1e4/0x260<br /> cpu_startup_entry+0x34/0x3c<br /> rest_init+0xdc/0xe0<br /> console_on_rootfs+0x0/0x6c<br /> __primary_switched+0x88/0x90<br /> ```

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: drr: Fix double list add in class with netem as child qdisc<br /> <br /> As described in Gerrard&amp;#39;s report [1], there are use cases where a netem<br /> child qdisc will make the parent qdisc&amp;#39;s enqueue callback reentrant.<br /> In the case of drr, there won&amp;#39;t be a UAF, but the code will add the same<br /> classifier to the list twice, which will cause memory corruption.<br /> <br /> In addition to checking for qlen being zero, this patch checks whether the<br /> class was already added to the active_list (cl_is_active) before adding<br /> to the list to cover for the reentrant case.<br /> <br /> [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pds_core: remove write-after-free of client_id<br /> <br /> A use-after-free error popped up in stress testing:<br /> <br /> [Mon Apr 21 21:21:33 2025] BUG: KFENCE: use-after-free write in pdsc_auxbus_dev_del+0xef/0x160 [pds_core]<br /> [Mon Apr 21 21:21:33 2025] Use-after-free write at 0x000000007013ecd1 (in kfence-#47):<br /> [Mon Apr 21 21:21:33 2025] pdsc_auxbus_dev_del+0xef/0x160 [pds_core]<br /> [Mon Apr 21 21:21:33 2025] pdsc_remove+0xc0/0x1b0 [pds_core]<br /> [Mon Apr 21 21:21:33 2025] pci_device_remove+0x24/0x70<br /> [Mon Apr 21 21:21:33 2025] device_release_driver_internal+0x11f/0x180<br /> [Mon Apr 21 21:21:33 2025] driver_detach+0x45/0x80<br /> [Mon Apr 21 21:21:33 2025] bus_remove_driver+0x83/0xe0<br /> [Mon Apr 21 21:21:33 2025] pci_unregister_driver+0x1a/0x80<br /> <br /> The actual device uninit usually happens on a separate thread<br /> scheduled after this code runs, but there is no guarantee of order<br /> of thread execution, so this could be a problem. There&amp;#39;s no<br /> actual need to clear the client_id at this point, so simply<br /> remove the offending code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: Fix race condition in AF_XDP generic RX path<br /> <br /> Move rx_lock from xsk_socket to xsk_buff_pool.<br /> Fix synchronization for shared umem mode in<br /> generic RX path where multiple sockets share<br /> single xsk_buff_pool.<br /> <br /> RX queue is exclusive to xsk_socket, while FILL<br /> queue can be shared between multiple sockets.<br /> This could result in race condition where two<br /> CPU cores access RX path of two different sockets<br /> sharing the same umem.<br /> <br /> Protect both queues by acquiring spinlock in shared<br /> xsk_buff_pool.<br /> <br /> Lock contention may be minimized in the future by some<br /> per-thread FQ buffering.<br /> <br /> It&amp;#39;s safe and necessary to move spin_lock_bh(rx_lock)<br /> after xsk_rcv_check():<br /> * xs-&gt;pool and spinlock_init is synchronized by<br /> xsk_bind() -&gt; xsk_is_bound() memory barriers.<br /> * xsk_rcv_check() may return true at the moment<br /> of xsk_release() or xsk_unbind_dev(),<br /> however this will not cause any data races or<br /> race conditions. xsk_unbind_dev() removes xdp<br /> socket from all maps and waits for completion<br /> of all outstanding rx operations. Packets in<br /> RX path will either complete safely or drop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: ocp: Fix NULL dereference in Adva board SMA sysfs operations<br /> <br /> On Adva boards, SMA sysfs store/get operations can call<br /> __handle_signal_outputs() or __handle_signal_inputs() while the `irig`<br /> and `dcf` pointers are uninitialized, leading to a NULL pointer<br /> dereference in __handle_signal() and causing a kernel crash. Adva boards<br /> don&amp;#39;t use `irig` or `dcf` functionality, so add Adva-specific callbacks<br /> `ptp_ocp_sma_adva_set_outputs()` and `ptp_ocp_sma_adva_set_inputs()` that<br /> avoid invoking `irig` or `dcf` input/output routines.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix out-of-bound memcpy() during ethtool -w<br /> <br /> When retrieving the FW coredump using ethtool, it can sometimes cause<br /> memory corruption:<br /> <br /> BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]<br /> Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):<br /> __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]<br /> ethtool_get_dump_data+0xdc/0x1a0<br /> __dev_ethtool+0xa1e/0x1af0<br /> dev_ethtool+0xa8/0x170<br /> dev_ioctl+0x1b5/0x580<br /> sock_do_ioctl+0xab/0xf0<br /> sock_ioctl+0x1ce/0x2e0<br /> __x64_sys_ioctl+0x87/0xc0<br /> do_syscall_64+0x5c/0xf0<br /> entry_SYSCALL_64_after_hwframe+0x78/0x80<br /> <br /> ...<br /> <br /> This happens when copying the coredump segment list in<br /> bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.<br /> The info-&gt;dest_buf buffer is allocated based on the number of coredump<br /> segments returned by the FW. The segment list is then DMA&amp;#39;ed by<br /> the FW and the length of the DMA is returned by FW. The driver then<br /> copies this DMA&amp;#39;ed segment list to info-&gt;dest_buf.<br /> <br /> In some cases, this DMA length may exceed the info-&gt;dest_buf length<br /> and cause the above BUG condition. Fix it by capping the copy<br /> length to not exceed the length of info-&gt;dest_buf. The extra<br /> DMA data contains no useful information.<br /> <br /> This code path is shared for the HWRM_DBG_COREDUMP_LIST and the<br /> HWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different<br /> for these 2 FW commands. To simplify the logic, we need to move<br /> the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE<br /> up, so that the new check to cap the copy length will work for both<br /> commands.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lan743x: Fix memleak issue when GSO enabled<br /> <br /> Always map the `skb` to the LS descriptor. Previously skb was<br /> mapped to EXT descriptor when the number of fragments is zero with<br /> GSO enabled. Mapping the skb to EXT descriptor prevents it from<br /> being freed, leading to a memory leak

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm, slab: clean up slab-&gt;obj_exts always<br /> <br /> When memory allocation profiling is disabled at runtime or due to an<br /> error, shutdown_mem_profiling() is called: slab-&gt;obj_exts which<br /> previously allocated remains.<br /> It won&amp;#39;t be cleared by unaccount_slab() because of<br /> mem_alloc_profiling_enabled() not true. It&amp;#39;s incorrect, slab-&gt;obj_exts<br /> should always be cleaned up in unaccount_slab() to avoid following error:<br /> <br /> [...]BUG: Bad page state in process...<br /> ..<br /> [...]page dumped because: page still charged to cgroup<br /> <br /> [andriy.shevchenko@linux.intel.com: fold need_slab_obj_ext() into its only user]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ivpu: Fix locking order in ivpu_job_submit<br /> <br /> Fix deadlock in job submission and abort handling.<br /> When a thread aborts currently executing jobs due to a fault,<br /> it first locks the global lock protecting submitted_jobs (#1).<br /> <br /> After the last job is destroyed, it proceeds to release the related context<br /> and locks file_priv (#2). Meanwhile, in the job submission thread,<br /> the file_priv lock (#2) is taken first, and then the submitted_jobs<br /> lock (#1) is obtained when a job is added to the submitted jobs list.<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> (for example due to a fault) (jobs submissions keep coming)<br /> <br /> lock(&amp;vdev-&gt;submitted_jobs_lock) #1<br /> ivpu_jobs_abort_all()<br /> job_destroy()<br /> lock(&amp;file_priv-&gt;lock) #2<br /> lock(&amp;vdev-&gt;submitted_jobs_lock) #1<br /> file_priv_release()<br /> lock(&amp;vdev-&gt;context_list_lock)<br /> lock(&amp;file_priv-&gt;lock) #2<br /> <br /> This order of locking causes a deadlock. To resolve this issue,<br /> change the order of locking in ivpu_job_submit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: ets: Fix double list add in class with netem as child qdisc<br /> <br /> As described in Gerrard&amp;#39;s report [1], there are use cases where a netem<br /> child qdisc will make the parent qdisc&amp;#39;s enqueue callback reentrant.<br /> In the case of ets, there won&amp;#39;t be a UAF, but the code will add the same<br /> classifier to the list twice, which will cause memory corruption.<br /> <br /> In addition to checking for qlen being zero, this patch checks whether<br /> the class was already added to the active_list (cl_is_active) before<br /> doing the addition to cater for the reentrant case.<br /> <br /> [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: qfq: Fix double list add in class with netem as child qdisc<br /> <br /> As described in Gerrard&amp;#39;s report [1], there are use cases where a netem<br /> child qdisc will make the parent qdisc&amp;#39;s enqueue callback reentrant.<br /> In the case of qfq, there won&amp;#39;t be a UAF, but the code will add the same<br /> classifier to the list twice, which will cause memory corruption.<br /> <br /> This patch checks whether the class was already added to the agg-&gt;active<br /> list (cl_is_active) before doing the addition to cater for the reentrant<br /> case.<br /> <br /> [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: fix race between io_uring_cmd_complete_in_task and ublk_cancel_cmd<br /> <br /> ublk_cancel_cmd() calls io_uring_cmd_done() to complete uring_cmd, but<br /> we may have scheduled task work via io_uring_cmd_complete_in_task() for<br /> dispatching request, then kernel crash can be triggered.<br /> <br /> Fix it by not trying to canceling the command if ublk block request is<br /> started.