Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi: Fix use-after-free and list corruption on sender error<br /> <br /> The analysis from Breno:<br /> <br /> When the SMI sender returns an error, smi_work() delivers an error<br /> response but then jumps back to restart without cleaning up properly:<br /> <br /> 1. intf-&gt;curr_msg is not cleared, so no new message is pulled<br /> 2. newmsg still points to the message, causing sender() to be called<br /> again with the same message<br /> 3. If sender() fails again, deliver_err_response() is called with<br /> the same recv_msg that was already queued for delivery<br /> <br /> This causes list_add corruption ("list_add double add") because the<br /> recv_msg is added to the user_msgs list twice. Subsequently, the<br /> corrupted list leads to use-after-free when the memory is freed and<br /> reused, and eventually a NULL pointer dereference when accessing<br /> recv_msg-&gt;done.<br /> <br /> The buggy sequence:<br /> <br /> sender() fails<br /> -&gt; deliver_err_response(recv_msg) // recv_msg queued for delivery<br /> -&gt; goto restart // curr_msg not cleared!<br /> sender() fails again (same message!)<br /> -&gt; deliver_err_response(recv_msg) // tries to queue same recv_msg<br /> -&gt; LIST CORRUPTION<br /> <br /> Fix this by freeing the message and setting it to NULL on a send error.<br /> Also, always free the newmsg on a send error, otherwise it will leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Fix NULL pointer dereference of mgmt_chann<br /> <br /> mgmt_chann may be set to NULL if the firmware returns an unexpected<br /> error in aie2_send_mgmt_msg_wait(). This can later lead to a NULL<br /> pointer dereference in aie2_hw_stop().<br /> <br /> Fix this by introducing a dedicated helper to destroy mgmt_chann<br /> and by adding proper NULL checks before accessing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/mbox: validate payload size before accessing contents in cxl_payload_from_user_allowed()<br /> <br /> cxl_payload_from_user_allowed() casts and dereferences the input<br /> payload without first verifying its size. When a raw mailbox command<br /> is sent with an undersized payload (ie: 1 byte for CXL_MBOX_OP_CLEAR_LOG,<br /> which expects a 16-byte UUID), uuid_equal() reads past the allocated buffer,<br /> triggering a KASAN splat:<br /> <br /> BUG: KASAN: slab-out-of-bounds in memcmp+0x176/0x1d0 lib/string.c:683<br /> Read of size 8 at addr ffff88810130f5c0 by task syz.1.62/2258<br /> <br /> CPU: 2 UID: 0 PID: 2258 Comm: syz.1.62 Not tainted 6.19.0-dirty #3 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0xab/0xe0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xce/0x650 mm/kasan/report.c:482<br /> kasan_report+0xce/0x100 mm/kasan/report.c:595<br /> memcmp+0x176/0x1d0 lib/string.c:683<br /> uuid_equal include/linux/uuid.h:73 [inline]<br /> cxl_payload_from_user_allowed drivers/cxl/core/mbox.c:345 [inline]<br /> cxl_mbox_cmd_ctor drivers/cxl/core/mbox.c:368 [inline]<br /> cxl_validate_cmd_from_user drivers/cxl/core/mbox.c:522 [inline]<br /> cxl_send_cmd+0x9c0/0xb50 drivers/cxl/core/mbox.c:643<br /> __cxl_memdev_ioctl drivers/cxl/core/memdev.c:698 [inline]<br /> cxl_memdev_ioctl+0x14f/0x190 drivers/cxl/core/memdev.c:713<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl fs/ioctl.c:583 [inline]<br /> __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xa8/0x330 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fdaf331ba79<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fdaf1d77038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007fdaf3585fa0 RCX: 00007fdaf331ba79<br /> RDX: 00002000000001c0 RSI: 00000000c030ce02 RDI: 0000000000000003<br /> RBP: 00007fdaf33749df R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007fdaf3586038 R14: 00007fdaf3585fa0 R15: 00007ffced2af768<br /> <br /> <br /> Add &amp;#39;in_size&amp;#39; parameter to cxl_payload_from_user_allowed() and validate<br /> the payload is large enough.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: Fix fragment node deletion to prevent buffer leak<br /> <br /> After commit b692bf9a7543 ("xsk: Get rid of xdp_buff_xsk::xskb_list_node"),<br /> the list_node field is reused for both the xskb pool list and the buffer<br /> free list, this causes a buffer leak as described below.<br /> <br /> xp_free() checks if a buffer is already on the free list using<br /> list_empty(&amp;xskb-&gt;list_node). When list_del() is used to remove a node<br /> from the xskb pool list, it doesn&amp;#39;t reinitialize the node pointers.<br /> This means list_empty() will return false even after the node has been<br /> removed, causing xp_free() to incorrectly skip adding the buffer to the<br /> free list.<br /> <br /> Fix this by using list_del_init() instead of list_del() in all fragment<br /> handling paths, this ensures the list node is reinitialized after removal,<br /> allowing the list_empty() to work correctly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: Fix possible oob access in mt7996_mac_write_txwi_80211()<br /> <br /> Check frame length before accessing the mgmt fields in<br /> mt7996_mac_write_txwi_80211 in order to avoid a possible oob access.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: in-kernel: always mark signal+subflow endp as used<br /> <br /> Syzkaller managed to find a combination of actions that was generating<br /> this warning:<br /> <br /> msk-&gt;pm.local_addr_used == 0<br /> WARNING: net/mptcp/pm_kernel.c:1071 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline], CPU#1: syz.2.17/961<br /> WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline], CPU#1: syz.2.17/961<br /> WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210, CPU#1: syz.2.17/961<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 961 Comm: syz.2.17 Not tainted 6.19.0-08368-gfafda3b4b06b #22 PREEMPT(full)<br /> Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.17.0-debian-1.17.0-1build1 04/01/2014<br /> RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline]<br /> RIP: 0010:mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline]<br /> RIP: 0010:mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210<br /> Code: 89 c5 e8 46 30 6f fe e9 21 fd ff ff 49 83 ed 80 e8 38 30 6f fe 4c 89 ef be 03 00 00 00 e8 db 49 df fe eb ac e8 24 30 6f fe 90 0b 90 e9 1d ff ff ff e8 16 30 6f fe eb 05 e8 0f 30 6f fe e8 9a<br /> RSP: 0018:ffffc90001663880 EFLAGS: 00010293<br /> RAX: ffffffff82de1a6c RBX: 0000000000000000 RCX: ffff88800722b500<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffff8880158b22d0 R08: 0000000000010425 R09: ffffffffffffffff<br /> R10: ffffffff82de18ba R11: 0000000000000000 R12: ffff88800641a640<br /> R13: ffff8880158b1880 R14: ffff88801ec3c900 R15: ffff88800641a650<br /> FS: 00005555722c3500(0000) GS:ffff8880f909d000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f66346e0f60 CR3: 000000001607c000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115<br /> genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]<br /> genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210<br /> netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550<br /> genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x4aa/0x5b0 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0xc9/0xf0 net/socket.c:742<br /> ____sys_sendmsg+0x272/0x3b0 net/socket.c:2592<br /> ___sys_sendmsg+0x2de/0x320 net/socket.c:2646<br /> __sys_sendmsg net/socket.c:2678 [inline]<br /> __do_sys_sendmsg net/socket.c:2683 [inline]<br /> __se_sys_sendmsg net/socket.c:2681 [inline]<br /> __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2681<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x143/0x440 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f66346f826d<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffc83d8bdc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f6634985fa0 RCX: 00007f66346f826d<br /> RDX: 00000000040000b0 RSI: 0000200000000740 RDI: 0000000000000007<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6634985fa8<br /> R13: 00007f6634985fac R14: 0000000000000000 R15: 0000000000001770<br /> <br /> <br /> The actions that caused that seem to be:<br /> <br /> - Set the MPTCP subflows limit to 0<br /> - Create an MPTCP endpoint with both the &amp;#39;signal&amp;#39; and &amp;#39;subflow&amp;#39; flags<br /> - Create a new MPTCP connection from a different address: an ADD_ADDR<br /> linked to the MPTCP endpoint will be sent (&amp;#39;signal&amp;#39; flag), but no<br /> subflows is initiated (&amp;#39;subflow&amp;#39; flag)<br /> - Remove the MPTCP endpoint<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix a UAF issue in bpf_trampoline_link_cgroup_shim<br /> <br /> The root cause of this bug is that when &amp;#39;bpf_link_put&amp;#39; reduces the<br /> refcount of &amp;#39;shim_link-&gt;link.link&amp;#39; to zero, the resource is considered<br /> released but may still be referenced via &amp;#39;tr-&gt;progs_hlist&amp;#39; in<br /> &amp;#39;cgroup_shim_find&amp;#39;. The actual cleanup of &amp;#39;tr-&gt;progs_hlist&amp;#39; in<br /> &amp;#39;bpf_shim_tramp_link_release&amp;#39; is deferred. During this window, another<br /> process can cause a use-after-free via &amp;#39;bpf_trampoline_link_cgroup_shim&amp;#39;.<br /> <br /> Based on Martin KaFai Lau&amp;#39;s suggestions, I have created a simple patch.<br /> <br /> To fix this:<br /> Add an atomic non-zero check in &amp;#39;bpf_trampoline_link_cgroup_shim&amp;#39;.<br /> Only increment the refcount if it is not already zero.<br /> <br /> Testing:<br /> I verified the fix by adding a delay in<br /> &amp;#39;bpf_shim_tramp_link_release&amp;#39; to make the bug easier to trigger:<br /> <br /> static void bpf_shim_tramp_link_release(struct bpf_link *link)<br /> {<br /> /* ... */<br /> if (!shim_link-&gt;trampoline)<br /> return;<br /> <br /> + msleep(100);<br /> WARN_ON_ONCE(bpf_trampoline_unlink_prog(&amp;shim_link-&gt;link,<br /> shim_link-&gt;trampoline, NULL));<br /> bpf_trampoline_put(shim_link-&gt;trampoline);<br /> }<br /> <br /> Before the patch, running a PoC easily reproduced the crash(almost 100%)<br /> with a call trace similar to KaiyanM&amp;#39;s report.<br /> After the patch, the bug no longer occurs even after millions of<br /> iterations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Use correct version for UAC3 header validation<br /> <br /> The entry of the validators table for UAC3 AC header descriptor is<br /> defined with the wrong protocol version UAC_VERSION_2, while it should<br /> have been UAC_VERSION_3. This results in the validator never matching<br /> for actual UAC3 devices (protocol == UAC_VERSION_3), causing their<br /> header descriptors to bypass validation entirely. A malicious USB<br /> device presenting a truncated UAC3 header could exploit this to cause<br /> out-of-bounds reads when the driver later accesses unvalidated<br /> descriptor fields.<br /> <br /> The bug was introduced in the same commit as the recently fixed UAC3<br /> feature unit sub-type typo, and appears to be from the same copy-paste<br /> error when the UAC3 section was created from the UAC2 section.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv4: fix ARM64 alignment fault in multipath hash seed<br /> <br /> `struct sysctl_fib_multipath_hash_seed` contains two u32 fields<br /> (user_seed and mp_seed), making it an 8-byte structure with a 4-byte<br /> alignment requirement.<br /> <br /> In `fib_multipath_hash_from_keys()`, the code evaluates the entire<br /> struct atomically via `READ_ONCE()`:<br /> <br /> mp_seed = READ_ONCE(net-&gt;ipv4.sysctl_fib_multipath_hash_seed).mp_seed;<br /> <br /> While this silently works on GCC by falling back to unaligned regular<br /> loads which the ARM64 kernel tolerates, it causes a fatal kernel panic<br /> when compiled with Clang and LTO enabled.<br /> <br /> Commit e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire<br /> when CONFIG_LTO=y") strengthens `READ_ONCE()` to use Load-Acquire<br /> instructions (`ldar` / `ldapr`) to prevent compiler reordering bugs<br /> under Clang LTO. Since the macro evaluates the full 8-byte struct,<br /> Clang emits a 64-bit `ldar` instruction. ARM64 architecture strictly<br /> requires `ldar` to be naturally aligned, thus executing it on a 4-byte<br /> aligned address triggers a strict Alignment Fault (FSC = 0x21).<br /> <br /> Fix the read side by moving the `READ_ONCE()` directly to the `u32`<br /> member, which emits a safe 32-bit `ldar Wn`.<br /> <br /> Furthermore, Eric Dumazet pointed out that `WRITE_ONCE()` on the entire<br /> struct in `proc_fib_multipath_hash_set_seed()` is also flawed. Analysis<br /> shows that Clang splits this 8-byte write into two separate 32-bit<br /> `str` instructions. While this avoids an alignment fault, it destroys<br /> atomicity and exposes a tear-write vulnerability. Fix this by<br /> explicitly splitting the write into two 32-bit `WRITE_ONCE()`<br /> operations.<br /> <br /> Finally, add the missing `READ_ONCE()` when reading `user_seed` in<br /> `proc_fib_multipath_hash_seed()` to ensure proper pairing and<br /> concurrency safety.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Return the correct value in vmw_translate_ptr functions<br /> <br /> Before the referenced fixes these functions used a lookup function that<br /> returned a pointer. This was changed to another lookup function that<br /> returned an error code with the pointer becoming an out parameter.<br /> <br /> The error path when the lookup failed was not changed to reflect this<br /> change and the code continued to return the PTR_ERR of the now<br /> uninitialized pointer. This could cause the vmw_translate_ptr functions<br /> to return success when they actually failed causing further uninitialized<br /> and OOB accesses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf/bonding: reject vlan+srcmac xmit_hash_policy change when XDP is loaded<br /> <br /> bond_option_mode_set() already rejects mode changes that would make a<br /> loaded XDP program incompatible via bond_xdp_check(). However,<br /> bond_option_xmit_hash_policy_set() has no such guard.<br /> <br /> For 802.3ad and balance-xor modes, bond_xdp_check() returns false when<br /> xmit_hash_policy is vlan+srcmac, because the 802.1q payload is usually<br /> absent due to hardware offload. This means a user can:<br /> <br /> 1. Attach a native XDP program to a bond in 802.3ad/balance-xor mode<br /> with a compatible xmit_hash_policy (e.g. layer2+3).<br /> 2. Change xmit_hash_policy to vlan+srcmac while XDP remains loaded.<br /> <br /> This leaves bond-&gt;xdp_prog set but bond_xdp_check() now returning false<br /> for the same device. When the bond is later destroyed, dev_xdp_uninstall()<br /> calls bond_xdp_set(dev, NULL, NULL) to remove the program, which hits<br /> the bond_xdp_check() guard and returns -EOPNOTSUPP, triggering:<br /> <br /> WARN_ON(dev_xdp_install(dev, mode, bpf_op, NULL, 0, NULL))<br /> <br /> Fix this by rejecting xmit_hash_policy changes to vlan+srcmac when an<br /> XDP program is loaded on a bond in 802.3ad or balance-xor mode.<br /> <br /> commit 39a0876d595b ("net, bonding: Disallow vlan+srcmac with XDP")<br /> introduced bond_xdp_check() which returns false for 802.3ad/balance-xor<br /> modes when xmit_hash_policy is vlan+srcmac. The check was wired into<br /> bond_xdp_set() to reject XDP attachment with an incompatible policy, but<br /> the symmetric path -- preventing xmit_hash_policy from being changed to an<br /> incompatible value after XDP is already loaded -- was left unguarded in<br /> bond_option_xmit_hash_policy_set().<br /> <br /> Note:<br /> commit 094ee6017ea0 ("bonding: check xdp prog when set bond mode")<br /> later added a similar guard to bond_option_mode_set(), but<br /> bond_option_xmit_hash_policy_set() remained unprotected.