Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> book3s64/radix : Align section vmemmap start address to PAGE_SIZE<br /> <br /> A vmemmap altmap is a device-provided region used to provide<br /> backing storage for struct pages. For each namespace, the altmap<br /> should belong to that same namespace. If the namespaces are<br /> created unaligned, there is a chance that the section vmemmap<br /> start address could also be unaligned. If the section vmemmap<br /> start address is unaligned, the altmap page allocated from the<br /> current namespace might be used by the previous namespace also.<br /> During the free operation, since the altmap is shared between two<br /> namespaces, the previous namespace may detect that the page does<br /> not belong to its altmap and incorrectly assume that the page is a<br /> normal page. It then attempts to free the normal page, which leads<br /> to a kernel crash.<br /> <br /> Kernel attempted to read user page (18) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000018<br /> Faulting instruction address: 0xc000000000530c7c<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries<br /> CPU: 32 PID: 2104 Comm: ndctl Kdump: loaded Tainted: G W<br /> NIP: c000000000530c7c LR: c000000000530e00 CTR: 0000000000007ffe<br /> REGS: c000000015e57040 TRAP: 0300 Tainted: G W<br /> MSR: 800000000280b033 CR: 84482404<br /> CFAR: c000000000530dfc DAR: 0000000000000018 DSISR: 40000000 IRQMASK: 0<br /> GPR00: c000000000530e00 c000000015e572e0 c000000002c5cb00 c00c000101008040<br /> GPR04: 0000000000000000 0000000000000007 0000000000000001 000000000000001f<br /> GPR08: 0000000000000005 0000000000000000 0000000000000018 0000000000002000<br /> GPR12: c0000000001d2fb0 c0000060de6b0080 0000000000000000 c0000060dbf90020<br /> GPR16: c00c000101008000 0000000000000001 0000000000000000 c000000125b20f00<br /> GPR20: 0000000000000001 0000000000000000 ffffffffffffffff c00c000101007fff<br /> GPR24: 0000000000000001 0000000000000000 0000000000000000 0000000000000000<br /> GPR28: 0000000004040201 0000000000000001 0000000000000000 c00c000101008040<br /> NIP [c000000000530c7c] get_pfnblock_flags_mask+0x7c/0xd0<br /> LR [c000000000530e00] free_unref_page_prepare+0x130/0x4f0<br /> Call Trace:<br /> free_unref_page+0x50/0x1e0<br /> free_reserved_page+0x40/0x68<br /> free_vmemmap_pages+0x98/0xe0<br /> remove_pte_table+0x164/0x1e8<br /> remove_pmd_table+0x204/0x2c8<br /> remove_pud_table+0x1c4/0x288<br /> remove_pagetable+0x1c8/0x310<br /> vmemmap_free+0x24/0x50<br /> section_deactivate+0x28c/0x2a0<br /> __remove_pages+0x84/0x110<br /> arch_remove_memory+0x38/0x60<br /> memunmap_pages+0x18c/0x3d0<br /> devm_action_release+0x30/0x50<br /> release_nodes+0x68/0x140<br /> devres_release_group+0x100/0x190<br /> dax_pmem_compat_release+0x44/0x80 [dax_pmem_compat]<br /> device_for_each_child+0x8c/0x100<br /> [dax_pmem_compat_remove+0x2c/0x50 [dax_pmem_compat]<br /> nvdimm_bus_remove+0x78/0x140 [libnvdimm]<br /> device_remove+0x70/0xd0<br /> <br /> Another issue is that if there is no altmap, a PMD-sized vmemmap<br /> page will be allocated from RAM, regardless of the alignment of<br /> the section start address. If the section start address is not<br /> aligned to the PMD size, a VM_BUG_ON will be triggered when<br /> setting the PMD-sized page to page table.<br /> <br /> In this patch, we are aligning the section vmemmap start address<br /> to PAGE_SIZE. After alignment, the start address will not be<br /> part of the current namespace, and a normal page will be allocated<br /> for the vmemmap mapping of the current section. For the remaining<br /> sections, altmaps will be allocated. During the free operation,<br /> the normal page will be correctly freed.<br /> <br /> In the same way, a PMD_SIZE vmemmap page will be allocated only if<br /> the section start address is PMD_SIZE-aligned; otherwise, it will<br /> fall back to a PAGE-sized vmemmap allocation.<br /> <br /> Without this patch<br /> ==================<br /> NS1 start NS2 start<br /> _________________________________________________________<br /> | NS1 | NS2 |<br /> ---------------------------------------------------------<br /> | Altmap| Altmap | .....|Altmap| Altmap | ...........<br /> | NS1 | NS1 <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: vnifilter: Fix unlocked deletion of default FDB entry<br /> <br /> When a VNI is deleted from a VXLAN device in &amp;#39;vnifilter&amp;#39; mode, the FDB<br /> entry associated with the default remote (assuming one was configured)<br /> is deleted without holding the hash lock. This is wrong and will result<br /> in a warning [1] being generated by the lockdep annotation that was<br /> added by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup").<br /> <br /> Reproducer:<br /> <br /> # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1<br /> # bridge vni add vni 10010 remote 198.51.100.1 dev vx0<br /> # bridge vni del vni 10010 dev vx0<br /> <br /> Fix by acquiring the hash lock before the deletion and releasing it<br /> afterwards. Blame the original commit that introduced the issue rather<br /> than the one that exposed it.<br /> <br /> [1]<br /> WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0<br /> [...]<br /> RIP: 0010:vxlan_find_mac+0x17f/0x1a0<br /> [...]<br /> Call Trace:<br /> <br /> __vxlan_fdb_delete+0xbe/0x560<br /> vxlan_vni_delete_group+0x2ba/0x940<br /> vxlan_vni_del.isra.0+0x15f/0x580<br /> vxlan_process_vni_filter+0x38b/0x7b0<br /> vxlan_vnifilter_process+0x3bb/0x510<br /> rtnetlink_rcv_msg+0x2f7/0xb70<br /> netlink_rcv_skb+0x131/0x360<br /> netlink_unicast+0x426/0x710<br /> netlink_sendmsg+0x75a/0xc20<br /> __sock_sendmsg+0xc1/0x150<br /> ____sys_sendmsg+0x5aa/0x7b0<br /> ___sys_sendmsg+0xfc/0x180<br /> __sys_sendmsg+0x121/0x1b0<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: amd: acp: Fix NULL pointer deref in acp_i2s_set_tdm_slot<br /> <br /> Update chip data using dev_get_drvdata(dev-&gt;parent) to fix<br /> NULL pointer deref in acp_i2s_set_tdm_slot.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: avoid NULL pointer dereference in skb_dequeue()<br /> <br /> A NULL pointer dereference can occur in skb_dequeue() when processing a<br /> QCA firmware crash dump on WCN7851 (0489:e0f3).<br /> <br /> [ 93.672166] Bluetooth: hci0: ACL memdump size(589824)<br /> <br /> [ 93.672475] BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> [ 93.672517] Workqueue: hci0 hci_devcd_rx [bluetooth]<br /> [ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80<br /> <br /> The issue stems from handle_dump_pkt_qca() returning 0 even when a dump<br /> packet is successfully processed. This is because it incorrectly<br /> forwards the return value of hci_devcd_init() (which returns 0 on<br /> success). As a result, the caller (btusb_recv_acl_qca() or<br /> btusb_recv_evt_qca()) assumes the packet was not handled and passes it<br /> to hci_recv_frame(), leading to premature kfree() of the skb.<br /> <br /> Later, hci_devcd_rx() attempts to dequeue the same skb from the dump<br /> queue, resulting in a NULL pointer dereference.<br /> <br /> Fix this by:<br /> 1. Making handle_dump_pkt_qca() return 0 on success and negative errno<br /> on failure, consistent with kernel conventions.<br /> 2. Splitting dump packet detection into separate functions for ACL<br /> and event packets for better structure and readability.<br /> <br /> This ensures dump packets are properly identified and consumed, avoiding<br /> double handling and preventing NULL pointer access.

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]