Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid<br /> <br /> There is a string parsing logic error which can lead to an overflow of hid<br /> or uid buffers. Comparing ACPIID_LEN against a total string length doesn&amp;#39;t<br /> take into account the lengths of individual hid and uid buffers so the<br /> check is insufficient in some cases. For example if the length of hid<br /> string is 4 and the length of the uid string is 260, the length of str<br /> will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer<br /> which size is 256.<br /> <br /> The same applies to the hid string with length 13 and uid string with<br /> length 250.<br /> <br /> Check the length of hid and uid strings separately to prevent<br /> buffer overflow.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: adjust subpage bit start based on sectorsize<br /> <br /> When running machines with 64k page size and a 16k nodesize we started<br /> seeing tree log corruption in production. This turned out to be because<br /> we were not writing out dirty blocks sometimes, so this in fact affects<br /> all metadata writes.<br /> <br /> When writing out a subpage EB we scan the subpage bitmap for a dirty<br /> range. If the range isn&amp;#39;t dirty we do<br /> <br /> bit_start++;<br /> <br /> to move onto the next bit. The problem is the bitmap is based on the<br /> number of sectors that an EB has. So in this case, we have a 64k<br /> pagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4<br /> bits for every node. With a 64k page size we end up with 4 nodes per<br /> page.<br /> <br /> To make this easier this is how everything looks<br /> <br /> [0 16k 32k 48k ] logical address<br /> [0 4 8 12 ] radix tree offset<br /> [ 64k page ] folio<br /> [ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers<br /> [ | | | | | | | | | | | | | | | | ] bitmap<br /> <br /> Now we use all of our addressing based on fs_info-&gt;sectorsize_bits, so<br /> as you can see the above our 16k eb-&gt;start turns into radix entry 4.<br /> <br /> When we find a dirty range for our eb, we correctly do bit_start +=<br /> sectors_per_node, because if we start at bit 0, the next bit for the<br /> next eb is 4, to correspond to eb-&gt;start 16k.<br /> <br /> However if our range is clean, we will do bit_start++, which will now<br /> put us offset from our radix tree entries.<br /> <br /> In our case, assume that the first time we check the bitmap the block is<br /> not dirty, we increment bit_start so now it == 1, and then we loop<br /> around and check again. This time it is dirty, and we go to find that<br /> start using the following equation<br /> <br /> start = folio_start + bit_start * fs_info-&gt;sectorsize;<br /> <br /> so in the case above, eb-&gt;start 0 is now dirty, and we calculate start<br /> as<br /> <br /> 0 + 1 * fs_info-&gt;sectorsize = 4096<br /> 4096 &gt;&gt; 12 = 1<br /> <br /> Now we&amp;#39;re looking up the radix tree for 1, and we won&amp;#39;t find an eb.<br /> What&amp;#39;s worse is now we&amp;#39;re using bit_start == 1, so we do bit_start +=<br /> sectors_per_node, which is now 5. If that eb is dirty we will run into<br /> the same thing, we will look at an offset that is not populated in the<br /> radix tree, and now we&amp;#39;re skipping the writeout of dirty extent buffers.<br /> <br /> The best fix for this is to not use sectorsize_bits to address nodes,<br /> but that&amp;#39;s a larger change. Since this is a fs corruption problem fix<br /> it simply by always using sectors_per_node to increment the start bit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sch_htb: make htb_qlen_notify() idempotent<br /> <br /> htb_qlen_notify() always deactivates the HTB class and in fact could<br /> trigger a warning if it is already deactivated. Therefore, it is not<br /> idempotent and not friendly to its callers, like fq_codel_dequeue().<br /> <br /> Let&amp;#39;s make it idempotent to ease qdisc_tree_reduce_backlog() callers&amp;#39;<br /> life.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeon_ep: Fix host hang issue during device reboot<br /> <br /> When the host loses heartbeat messages from the device,<br /> the driver calls the device-specific ndo_stop function,<br /> which frees the resources. If the driver is unloaded in<br /> this scenario, it calls ndo_stop again, attempting to free<br /> resources that have already been freed, leading to a host<br /> hang issue. To resolve this, dev_close should be called<br /> instead of the device-specific stop function.dev_close<br /> internally calls ndo_stop to stop the network interface<br /> and performs additional cleanup tasks. During the driver<br /> unload process, if the device is already down, ndo_stop<br /> is not called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in kerberos authentication<br /> <br /> Setting sess-&gt;user = NULL was introduced to fix the dangling pointer<br /> created by ksmbd_free_user. However, it is possible another thread could<br /> be operating on the session and make use of sess-&gt;user after it has been<br /> passed to ksmbd_free_user but before sess-&gt;user is set to NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in ksmbd_session_rpc_open<br /> <br /> A UAF issue can occur due to a race condition between<br /> ksmbd_session_rpc_open() and __session_rpc_close().<br /> Add rpc_lock to the session to protect it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix oob write in trace_seq_to_buffer()<br /> <br /> syzbot reported this bug:<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]<br /> BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822<br /> Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260<br /> <br /> CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xc3/0x670 mm/kasan/report.c:521<br /> kasan_report+0xe0/0x110 mm/kasan/report.c:634<br /> check_region_inline mm/kasan/generic.c:183 [inline]<br /> kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189<br /> __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106<br /> trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]<br /> tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822<br /> ....<br /> ==================================================================<br /> <br /> It has been reported that trace_seq_to_buffer() tries to copy more data<br /> than PAGE_SIZE to buf. Therefore, to prevent this, we should use the<br /> smaller of trace_seq_used(&amp;iter-&gt;seq) and PAGE_SIZE as an argument.

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 /> ```