Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mshv: Fix error handling in mshv_region_pin<br /> <br /> The current error handling has two issues:<br /> <br /> First, pin_user_pages_fast() can return a short pin count (less than<br /> requested but greater than zero) when it cannot pin all requested pages.<br /> This is treated as success, leading to partially pinned regions being<br /> used, which causes memory corruption.<br /> <br /> Second, when an error occurs mid-loop, already pinned pages from the<br /> current batch are not properly accounted for before calling<br /> mshv_region_invalidate_pages(), causing a page reference leak.<br /> <br /> Treat short pins as errors and fix partial batch accounting before<br /> cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip6_tunnel: clear skb2-&gt;cb[] in ip4ip6_err()<br /> <br /> Oskar Kjos reported the following problem.<br /> <br /> ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written<br /> by the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes<br /> IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region<br /> as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff<br /> at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr<br /> value. __ip_options_echo() then reads optlen from attacker-controlled<br /> packet data at sptr[rr+1] and copies that many bytes into dopt-&gt;__data,<br /> a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE).<br /> <br /> To fix this we clear skb2-&gt;cb[], as suggested by Oskar Kjos.<br /> <br /> Also add minimal IPv4 header validation (version == 4, ihl &gt;= 5).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: set backing store type from query type<br /> <br /> bnxt_hwrm_func_backing_store_qcaps_v2() stores resp-&gt;type from the<br /> firmware response in ctxm-&gt;type and later uses that value to index<br /> fixed backing-store metadata arrays such as ctx_arr[] and<br /> bnxt_bstore_to_trace[].<br /> <br /> ctxm-&gt;type is fixed by the current backing-store query type and matches<br /> the array index of ctx-&gt;ctx_arr. Set ctxm-&gt;type from the current loop<br /> variable instead of depending on resp-&gt;type.<br /> <br /> Also update the loop to advance type from next_valid_type in the for<br /> statement, which keeps the control flow simpler for non-valid and<br /> unchanged entries.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to zero to prevent an info-leak<br /> <br /> When building netlink messages, tc_chain_fill_node() never initializes<br /> the tcm_info field of struct tcmsg. Since the allocation is not zeroed,<br /> kernel heap memory is leaked to userspace through this 4-byte field.<br /> <br /> The fix simply zeroes tcm_info alongside the other fields that are<br /> already initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: use skb_header_pointer() for TCPv4 GSO frag_off check<br /> <br /> Syzbot reported a KMSAN uninit-value warning in gso_features_check()<br /> called from netif_skb_features() [1].<br /> <br /> gso_features_check() reads iph-&gt;frag_off to decide whether to clear<br /> mangleid_features. Accessing the IPv4 header via ip_hdr()/inner_ip_hdr()<br /> can rely on skb header offsets that are not always safe for direct<br /> dereference on packets injected from PF_PACKET paths.<br /> <br /> Use skb_header_pointer() for the TCPv4 frag_off check so the header read<br /> is robust whether data is already linear or needs copying.<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: icmp: clear skb2-&gt;cb[] in ip6_err_gen_icmpv6_unreach()<br /> <br /> Sashiko AI-review observed:<br /> <br /> In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet<br /> where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2<br /> and passed to icmp6_send(), it uses IP6CB(skb2).<br /> <br /> IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso<br /> offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm<br /> at offset 18.<br /> <br /> If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao<br /> would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called<br /> and uses ipv6_find_tlv(skb, opt-&gt;dsthao, IPV6_TLV_HAO).<br /> <br /> This would scan the inner, attacker-controlled IPv6 packet starting at that<br /> offset, potentially returning a fake TLV without checking if the remaining<br /> packet length can hold the full 18-byte struct ipv6_destopt_hao.<br /> <br /> Could mip6_addr_swap() then perform a 16-byte swap that extends past the end<br /> of the packet data into skb_shared_info?<br /> <br /> Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and<br /> ip6ip6_err() to prevent this?<br /> <br /> This patch implements the first suggestion.<br /> <br /> I am not sure if ip6ip6_err() needs to be changed.<br /> A separate patch would be better anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent<br /> <br /> ctnetlink_alloc_expect() allocates expectations from a non-zeroing<br /> slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not<br /> present in the netlink message, saved_addr and saved_proto are<br /> never initialized. Stale data from a previous slab occupant can<br /> then be dumped to userspace by ctnetlink_exp_dump_expect(), which<br /> checks these fields to decide whether to emit CTA_EXPECT_NAT.<br /> <br /> The safe sibling nf_ct_expect_init(), used by the packet path,<br /> explicitly zeroes these fields.<br /> <br /> Zero saved_addr, saved_proto and dir in the else branch, guarded<br /> by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when<br /> NAT is enabled.<br /> <br /> Confirmed by priming the expect slab with NAT-bearing expectations,<br /> freeing them, creating a new expectation without CTA_EXPECT_NAT,<br /> and observing that the ctnetlink dump emits a spurious<br /> CTA_EXPECT_NAT containing stale data from the prior allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_helper: pass helper to expect cleanup<br /> <br /> nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy()<br /> to remove expectations belonging to the helper being unregistered.<br /> However, it passes NULL instead of the helper pointer as the data<br /> argument, so expect_iter_me() never matches any expectation and all<br /> of them survive the cleanup.<br /> <br /> After unregister returns, nfnl_cthelper_del() frees the helper<br /> object immediately. Subsequent expectation dumps or packet-driven<br /> init_conntrack() calls then dereference the freed exp-&gt;helper,<br /> causing a use-after-free.<br /> <br /> Pass the actual helper pointer so expectations referencing it are<br /> properly destroyed before the helper object is freed.<br /> <br /> BUG: KASAN: slab-use-after-free in string+0x38f/0x430<br /> Read of size 1 at addr ffff888003b14d20 by task poc/103<br /> Call Trace:<br /> string+0x38f/0x430<br /> vsnprintf+0x3cc/0x1170<br /> seq_printf+0x17a/0x240<br /> exp_seq_show+0x2e5/0x560<br /> seq_read_iter+0x419/0x1280<br /> proc_reg_read+0x1ac/0x270<br /> vfs_read+0x179/0x930<br /> ksys_read+0xef/0x1c0<br /> Freed by task 103:<br /> The buggy address is located 32 bytes inside of<br /> freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: ensure names are nul-terminated<br /> <br /> Reject names that lack a \0 character before feeding them<br /> to functions that expect c-strings.<br /> <br /> Fixes tag is the most recent commit that needs this change.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix soft lockup in mptcp_recvmsg()<br /> <br /> syzbot reported a soft lockup in mptcp_recvmsg() [0].<br /> <br /> When receiving data with MSG_PEEK | MSG_WAITALL flags, the skb is not<br /> removed from the sk_receive_queue. This causes sk_wait_data() to always<br /> find available data and never perform actual waiting, leading to a soft<br /> lockup.<br /> <br /> Fix this by adding a &amp;#39;last&amp;#39; parameter to track the last peeked skb.<br /> This allows sk_wait_data() to make informed waiting decisions and prevent<br /> infinite loops when MSG_PEEK is used.<br /> <br /> [0]:<br /> watchdog: BUG: soft lockup - CPU#2 stuck for 156s! [server:1963]<br /> Modules linked in:<br /> CPU: 2 UID: 0 PID: 1963 Comm: server Not tainted 6.19.0-rc8 #61 PREEMPT(none)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:sk_wait_data+0x15/0x190<br /> Code: 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 41 56 41 55 41 54 49 89 f4 55 48 89 d5 53 48 89 fb 83 ec 30 65 48 8b 05 17 a4 6b 01 48 89 44 24 28 31 c0 65 48 8b<br /> RSP: 0018:ffffc90000603ca0 EFLAGS: 00000246<br /> RAX: 0000000000000000 RBX: ffff888102bf0800 RCX: 0000000000000001<br /> RDX: 0000000000000000 RSI: ffffc90000603d18 RDI: ffff888102bf0800<br /> RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000101<br /> R10: 0000000000000000 R11: 0000000000000075 R12: ffffc90000603d18<br /> R13: ffff888102bf0800 R14: ffff888102bf0800 R15: 0000000000000000<br /> FS: 00007f6e38b8c4c0(0000) GS:ffff8881b877e000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055aa7bff1680 CR3: 0000000105cbe000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> mptcp_recvmsg+0x547/0x8c0 net/mptcp/protocol.c:2329<br /> inet_recvmsg+0x11f/0x130 net/ipv4/af_inet.c:891<br /> sock_recvmsg+0x94/0xc0 net/socket.c:1100<br /> __sys_recvfrom+0xb2/0x130 net/socket.c:2256<br /> __x64_sys_recvfrom+0x1f/0x30 net/socket.c:2267<br /> do_syscall_64+0x59/0x2d0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:131<br /> RIP: 0033:0x7f6e386a4a1d<br /> Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8d 05 f1 de 2c 00 41 89 ca 8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2d 00 00 00 0f 05 3d 00 f0 ff ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41<br /> RSP: 002b:00007ffc3c4bb078 EFLAGS: 00000246 ORIG_RAX: 000000000000002d<br /> RAX: ffffffffffffffda RBX: 000000000000861e RCX: 00007f6e386a4a1d<br /> RDX: 00000000000003ff RSI: 00007ffc3c4bb150 RDI: 0000000000000004<br /> RBP: 00007ffc3c4bb570 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000103 R11: 0000000000000246 R12: 00005605dbc00be0<br /> R13: 00007ffc3c4bb650 R14: 0000000000000000 R15: 0000000000000000<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix regsafe() for pointers to packet<br /> <br /> In case rold-&gt;reg-&gt;range == BEYOND_PKT_END &amp;&amp; rcur-&gt;reg-&gt;range == N<br /> regsafe() may return true which may lead to current state with<br /> valid packet range not being explored. Fix the bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets<br /> <br /> When a TX packet spans multiple buffer descriptors (scatter-gather),<br /> axienet_free_tx_chain sums the per-BD actual length from descriptor<br /> status into a caller-provided accumulator. That sum is reset on each<br /> NAPI poll. If the BDs for a single packet complete across different<br /> polls, the earlier bytes are lost and never credited to BQL. This<br /> causes BQL to think bytes are permanently in-flight, eventually<br /> stalling the TX queue.<br /> <br /> The SKB pointer is stored only on the last BD of a packet. When that<br /> BD completes, use skb-&gt;len for the byte count instead of summing<br /> per-BD status lengths. This matches netdev_sent_queue(), which debits<br /> skb-&gt;len, and naturally survives across polls because no partial<br /> packet contributes to the accumulator.