Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btmtk: validate WMT event SKB length before struct access<br /> <br /> btmtk_usb_hci_wmt_sync() casts the WMT event response SKB data to<br /> struct btmtk_hci_wmt_evt (7 bytes) and struct btmtk_hci_wmt_evt_funcc<br /> (9 bytes) without first checking that the SKB contains enough data.<br /> A short firmware response causes out-of-bounds reads from SKB tailroom.<br /> <br /> Use skb_pull_data() to validate and advance past the base WMT event<br /> header. For the FUNC_CTRL case, pull the additional status field bytes<br /> before accessing them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi: Check event message buffer response for bad data<br /> <br /> The event message buffer response data size got checked later when<br /> processing, but check it right after the response comes back. It<br /> appears some BMCs may return an empty message instead of an error<br /> when fetching events.<br /> <br /> There are apparently some new BMCs that make this error, so we need to<br /> compensate.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/ocrdma: Don&amp;#39;t NULL deref uctx on errors in ocrdma_copy_pd_uresp()<br /> <br /> Sashiko points out that pd-&gt;uctx isn&amp;#39;t initialized until late in the<br /> function so all these error flow references are NULL and will crash. Use<br /> the uctx that isn&amp;#39;t NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mana: Fix mana_destroy_wq_obj() cleanup in mana_ib_create_qp_rss()<br /> <br /> Sashiko points out there are two bugs here in the error unwind flow, both<br /> related to how the WQ table is unwound.<br /> <br /> First there is a double i-- on the first failure path due to the while loop<br /> having a i--, remove it.<br /> <br /> Second if mana_ib_install_cq_cb() fails then mana_create_wq_obj() is not<br /> undone due to the above i--.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/chrome: cros_ec_typec: Init mutex in Thunderbolt registration<br /> <br /> cros_typec_register_thunderbolt() missed initializing the `adata-&gt;lock`<br /> mutex. This leads to a NULL dereference when the mutex is later<br /> acquired (e.g. in cros_typec_altmode_work()).<br /> <br /> Initialize the mutex in cros_typec_register_thunderbolt() to fix the<br /> issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Reject unknown opcodes before ICRC processing<br /> <br /> Even after applying commit 7244491dab34 ("RDMA/rxe: Validate pad and ICRC<br /> before payload_size() in rxe_rcv"), a single unauthenticated UDP packet<br /> can still trigger panic. That patch handled payload_size() underflow only<br /> for valid opcodes with short packets, not for packets carrying an unknown<br /> opcode. The unknown-opcode OOB read described below predates that commit<br /> and reaches back to the initial Soft RoCE driver.<br /> <br /> The check added there reads<br /> <br /> pkt-&gt;paylen opcode].length. The<br /> rxe_opcode[] array has 256 entries but is only populated for defined IB<br /> opcodes; any other entry (for example opcode 0xff) is zero-initialized, so<br /> length == 0 and the check degenerates to<br /> <br /> pkt-&gt;paylen paylen enough. rxe_icrc_hdr() then computes<br /> <br /> rxe_opcode[pkt-&gt;opcode].length - RXE_BTH_BYTES<br /> <br /> which underflows when length == 0 and passes a huge value to rxe_crc32(),<br /> causing an out-of-bounds read of the skb payload.<br /> <br /> Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with<br /> CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after<br /> <br /> rdma link add rxe0 type rxe netdev eth0<br /> <br /> A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and<br /> QPN=IB_MULTICAST_QPN triggers:<br /> <br /> BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170<br /> Read of size 1 at addr ...<br /> The buggy address is located 0 bytes to the right of<br /> allocated 704-byte region<br /> Call Trace:<br /> crc32_le+0x115/0x170<br /> rxe_icrc_hdr.isra.0+0x226/0x300<br /> rxe_icrc_check+0x13f/0x3a0<br /> rxe_rcv+0x6e1/0x16e0<br /> rxe_udp_encap_recv+0x20a/0x320<br /> udp_queue_rcv_one_skb+0x7ed/0x12c0<br /> <br /> Subsequent packets with the same shape fault on unmapped memory and panic<br /> the kernel. The trigger requires only module load and "rdma link add"; no<br /> QP, no connection, and no authentication.<br /> <br /> Fix this by rejecting packets whose opcode has no rxe_opcode[] entry,<br /> detected via the zero mask or zero length, before any length arithmetic<br /> runs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo<br /> <br /> rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack<br /> without initialisation:<br /> <br /> struct ifla_vf_broadcast vf_broadcast;<br /> <br /> The struct contains a single fixed 32-byte field:<br /> <br /> /* include/uapi/linux/if_link.h */<br /> struct ifla_vf_broadcast {<br /> __u8 broadcast[32];<br /> };<br /> <br /> The function then copies dev-&gt;broadcast into it using dev-&gt;addr_len<br /> as the length:<br /> <br /> memcpy(vf_broadcast.broadcast, dev-&gt;broadcast, dev-&gt;addr_len);<br /> <br /> On Ethernet devices (the overwhelming majority of SR-IOV NICs)<br /> dev-&gt;addr_len is 6, so only the first 6 bytes of broadcast[] are<br /> written. The remaining 26 bytes retain whatever was previously on<br /> the kernel stack. The full struct is then handed to userspace via:<br /> <br /> nla_put(skb, IFLA_VF_BROADCAST,<br /> sizeof(vf_broadcast), &amp;vf_broadcast)<br /> <br /> leaking up to 26 bytes of uninitialised kernel stack per VF per<br /> RTM_GETLINK request, repeatable.<br /> <br /> The other vf_* structs in the same function are explicitly zeroed<br /> for exactly this reason - see the memset() calls for ivi,<br /> vf_vlan_info, node_guid and port_guid a few lines above.<br /> vf_broadcast was simply missed when it was added.<br /> <br /> Reachability: any unprivileged local process can open AF_NETLINK /<br /> NETLINK_ROUTE without capabilities and send RTM_GETLINK with an<br /> IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks<br /> each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per<br /> VF per request. Stack residue at this call site can include return<br /> addresses and transient sensitive data; KASAN with stack<br /> instrumentation, or KMSAN, will flag the nla_put() when reproduced.<br /> <br /> Zero the on-stack struct before the partial memcpy, matching the<br /> existing pattern used for the other vf_* structs in the same<br /> function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: check for nEPT/nNPT in slow flush hypercalls<br /> <br /> Checking is_guest_mode(vcpu) is incorrect, because translate_nested_gpa()<br /> is only valid if an L2 guest is running *with nested EPT/NPT enabled*.<br /> Instead use the same condition as translate_nested_gpa() itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-verity-fec: fix reading parity bytes split across blocks (take 3)<br /> <br /> fec_decode_bufs() assumes that the parity bytes of the first RS codeword<br /> it decodes are never split across parity blocks.<br /> <br /> This assumption is false. Consider v-&gt;fec-&gt;block_size == 4096 &amp;&amp;<br /> v-&gt;fec-&gt;roots == 17 &amp;&amp; fio-&gt;nbufs == 1, for example. In that case, each<br /> call to fec_decode_bufs() consumes v-&gt;fec-&gt;roots * (fio-&gt;nbufs

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix double free in create_space_info() error path<br /> <br /> When kobject_init_and_add() fails, the call chain is:<br /> <br /> create_space_info()<br /> -&gt; btrfs_sysfs_add_space_info_type()<br /> -&gt; kobject_init_and_add()<br /> -&gt; failure<br /> -&gt; kobject_put(&amp;space_info-&gt;kobj)<br /> -&gt; space_info_release()<br /> -&gt; kfree(space_info)<br /> <br /> Then control returns to create_space_info():<br /> <br /> btrfs_sysfs_add_space_info_type() returns error<br /> -&gt; goto out_free<br /> -&gt; kfree(space_info)<br /> <br /> This causes a double free.<br /> <br /> Keep the direct kfree(space_info) for the earlier failure path, but<br /> after btrfs_sysfs_add_space_info_type() has called kobject_put(), let<br /> the kobject release callback handle the cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: remove station if connection prep fails<br /> <br /> If connection preparation fails for MLO connections, then the<br /> interface is completely reset to non-MLD. In this case, we must<br /> not keep the station since it&amp;#39;s related to the link of the vif<br /> being removed. Delete an existing station. Any "new_sta" is<br /> already being removed, so that doesn&amp;#39;t need changes.<br /> <br /> This fixes a use-after-free/double-free in debugfs if that&amp;#39;s<br /> enabled, because a vif going from MLD (and to MLD, but that&amp;#39;s<br /> not relevant here) recreates its entire debugfs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> isofs: validate block number from NFS file handle in isofs_export_iget<br /> <br /> isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker-<br /> controlled block number (ifid-&gt;block or ifid-&gt;parent_block) from<br /> the NFS file handle to isofs_export_iget(), which only rejects<br /> block == 0 before calling isofs_iget() and ultimately sb_bread().<br /> A crafted file handle with fh_len sufficient to pass the check<br /> added by commit 0405d4b63d08 ("isofs: Prevent the use of too small<br /> fid") can still drive the server to read any in-range block on the<br /> backing device as if it were an iso_directory_record. That earlier<br /> fix was assigned CVE-2025-37780.<br /> <br /> sb_bread() on an out-of-range block returns NULL cleanly via the<br /> EIO path, so there is no memory-safety violation. For in-range<br /> reads of adjacent-partition data on the same block device, the<br /> unrelated bytes end up in iso_inode_info fields that reach the NFS<br /> client as dentry metadata. The deployment surface (isofs exported<br /> over NFS from loop-mounted images) is narrow and requires an<br /> authenticated NFS peer, but the malformed-file-handle class is<br /> reportable as hardening next to the existing CVE-2025-37780 fix.<br /> <br /> Reject block &gt;= ISOFS_SB(sb)-&gt;s_nzones in isofs_export_iget() so<br /> the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent()<br /> call sites with a single line.