Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak<br /> <br /> When processing Router Advertisements with user options the kernel<br /> builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct<br /> has three padding fields that are never zeroed and can leak kernel data<br /> <br /> The fix is simple, just zeroes the padding fields.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak<br /> <br /> __radix_tree_create() allocates and links intermediate nodes into the<br /> tree one by one. If a subsequent allocation fails, the already-linked<br /> nodes remain in the tree with no corresponding leaf entry. These orphaned<br /> internal nodes are never reclaimed because radix_tree_for_each_slot()<br /> only visits slots containing leaf values.<br /> <br /> The radix_tree API is deprecated in favor of xarray. As suggested by<br /> Matthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray instead<br /> of fixing the radix_tree itself [1]. xarray properly handles cleanup of<br /> internal nodes — xa_destroy() frees all internal xarray nodes when the<br /> qrtr_node is released, preventing the leak.<br /> <br /> [1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mpls: add seqcount to protect the platform_label{,s} pair<br /> <br /> The RCU-protected codepaths (mpls_forward, mpls_dump_routes) can have<br /> an inconsistent view of platform_labels vs platform_label in case of a<br /> concurrent resize (resize_platform_label_table, under<br /> platform_mutex). This can lead to OOB accesses.<br /> <br /> This patch adds a seqcount, so that we get a consistent snapshot.<br /> <br /> Note that mpls_label_ok is also susceptible to this, so the check<br /> against RTA_DST in rtm_to_route_config, done outside platform_mutex,<br /> is not sufficient. This value gets passed to mpls_label_ok once more<br /> in both mpls_route_add and mpls_route_del, so there is no issue, but<br /> that additional check must not be removed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: af-alg - fix NULL pointer dereference in scatterwalk<br /> <br /> The AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL)<br /> when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL<br /> exactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent<br /> sendmsg() allocates a new SGL and chains it, but fails to clear the end<br /> marker on the previous SGL&amp;#39;s last data entry.<br /> <br /> This causes the crypto scatterwalk to hit a premature end, returning NULL<br /> on sg_next() and leading to a kernel panic during dereference.<br /> <br /> Fix this by explicitly unmarking the end of the previous SGL when<br /> performing sg_chain() in af_alg_alloc_tsgl().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: caam - fix DMA corruption on long hmac keys<br /> <br /> When a key longer than block size is supplied, it is copied and then<br /> hashed into the real key. The memory allocated for the copy needs to<br /> be rounded to DMA cache alignment, as otherwise the hashed key may<br /> corrupt neighbouring memory.<br /> <br /> The rounding was performed, but never actually used for the allocation.<br /> Fix this by replacing kmemdup with kmalloc for a larger buffer,<br /> followed by memcpy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: reject root items with drop_progress and zero drop_level<br /> <br /> [BUG]<br /> When recovering relocation at mount time, merge_reloc_root() and<br /> btrfs_drop_snapshot() both use BUG_ON(level == 0) to guard against<br /> an impossible state: a non-zero drop_progress combined with a zero<br /> drop_level in a root_item, which can be triggered:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/relocation.c:1545!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary)<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2<br /> RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545<br /> Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000<br /> Call Trace:<br /> merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861<br /> btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195<br /> btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130<br /> open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640<br /> btrfs_fill_super fs/btrfs/super.c:987 [inline]<br /> btrfs_get_tree_super fs/btrfs/super.c:1951 [inline]<br /> btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline]<br /> btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128<br /> vfs_get_tree+0x9a/0x370 fs/super.c:1758<br /> fc_mount fs/namespace.c:1199 [inline]<br /> do_new_mount_fc fs/namespace.c:3642 [inline]<br /> do_new_mount fs/namespace.c:3718 [inline]<br /> path_mount+0x5b8/0x1ea0 fs/namespace.c:4028<br /> do_mount fs/namespace.c:4041 [inline]<br /> __do_sys_mount fs/namespace.c:4229 [inline]<br /> __se_sys_mount fs/namespace.c:4206 [inline]<br /> __x64_sys_mount+0x282/0x320 fs/namespace.c:4206<br /> ...<br /> RIP: 0033:0x7f969c9a8fde<br /> Code: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamic<br /> metadata fuzzing tool that corrupts btrfs metadata at runtime.<br /> <br /> [CAUSE]<br /> A non-zero drop_progress.objectid means an interrupted<br /> btrfs_drop_snapshot() left a resume point on disk, and in that case<br /> drop_level must be greater than 0 because the checkpoint is only<br /> saved at internal node levels.<br /> <br /> Although this invariant is enforced when the kernel writes the root<br /> item, it is not validated when the root item is read back from disk.<br /> That allows on-disk corruption to provide an invalid state with<br /> drop_progress.objectid != 0 and drop_level == 0.<br /> <br /> When relocation recovery later processes such a root item,<br /> merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). The<br /> same invalid metadata can also trigger the corresponding BUG_ON() in<br /> btrfs_drop_snapshot().<br /> <br /> [FIX]<br /> Fix this by validating the root_item invariant in tree-checker when<br /> reading root items from disk: if drop_progress.objectid is non-zero,<br /> drop_level must also be non-zero. Reject such malformed metadata with<br /> -EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot()<br /> and triggers the BUG_ON.<br /> <br /> After the fix, the same corruption is correctly rejected by tree-checker<br /> and the BUG_ON is no longer triggered.

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.