Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: virtio_bt: clamp rx length before skb_put<br /> <br /> virtbt_rx_work() calls skb_put(skb, len) where len comes directly<br /> from virtqueue_get_buf() with no validation against the buffer we<br /> posted to the device. The RX skb is allocated in virtbt_add_inbuf()<br /> and exposed to virtio as exactly 1000 bytes via sg_init_one().<br /> <br /> Checking len against skb_tailroom(skb) is not sufficient because<br /> alloc_skb() can leave more tailroom than the 1000 bytes actually<br /> handed to the device. A malicious or buggy backend can therefore<br /> report used.len between 1001 and skb_tailroom(skb), causing skb_put()<br /> to include uninitialized kernel heap bytes that were never written by<br /> the device.<br /> <br /> The same path also accepts len == 0, in which case skb_put(skb, 0)<br /> leaves the skb empty but virtbt_rx_handle() still reads the pkt_type<br /> byte from skb-&gt;data, consuming uninitialized memory.<br /> <br /> Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and<br /> sg_init_one(), and gate virtbt_rx_work() on that same constant so<br /> the bound checked matches the buffer actually exposed to the device.<br /> Reject used.len == 0 in the same gate so an empty completion can<br /> no longer reach virtbt_rx_handle().<br /> <br /> Use bt_dev_err_ratelimited() because the length value comes from an<br /> untrusted backend that can otherwise flood the kernel log.<br /> <br /> Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer<br /> overflow in USB transport layer"), which hardened the USB 9p<br /> transport against unchecked device-reported length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: b43: enforce bounds check on firmware key index in b43_rx()<br /> <br /> The firmware-controlled key index in b43_rx() can exceed the dev-&gt;key[]<br /> array size (58 entries). The existing B43_WARN_ON is non-enforcing in<br /> production builds, allowing an out-of-bounds read.<br /> <br /> Make the B43_WARN_ON check enforcing by dropping the frame when the<br /> firmware returns an invalid key index.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lock<br /> <br /> Patch series "mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path".<br /> <br /> Reads of &amp;#39;memcg_path&amp;#39; and &amp;#39;path&amp;#39; files in DAMON sysfs interface could race<br /> with their writes, results in use-after-free. Fix those.<br /> <br /> <br /> This patch (of 2):<br /> <br /> damon_sysfs_scheme_filter-&gt;mmecg_path can be read and written by users,<br /> via DAMON sysfs memcg_path file. It can also be indirectly read, for the<br /> parameters {on,off}line committing to DAMON. The reads for parameters<br /> committing are protected by damon_sysfs_lock to avoid the sysfs files<br /> being destroyed while any of the parameters are being read. But the<br /> user-driven direct reads and writes are not protected by any lock, while<br /> the write is deallocating the memcg_path-pointing buffer. As a result,<br /> the readers could read the already freed buffer (user-after-free). Note<br /> that the user-reads don&amp;#39;t race when the same open file is used by the<br /> writer, due to kernfs&amp;#39;s open file locking. Nonetheless, doing the reads<br /> and writes with separate open files would be common. Fix it by protecting<br /> both the user-direct reads and writes with damon_sysfs_lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip6_gre: Use cached t-&gt;net in ip6erspan_changelink().<br /> <br /> After commit 5e72ce3e3980 ("net: ipv6: Use link netns in newlink() of<br /> rtnl_link_ops"), ip6erspan_newlink() correctly resolves the per-netns<br /> ip6gre hash via link_net. ip6erspan_changelink() was not converted in<br /> that series and still uses dev_net(dev), which diverges from the<br /> device&amp;#39;s creation netns after IFLA_NET_NS_FD migration.<br /> <br /> This re-inserts the tunnel into the wrong per-netns hash. The<br /> original netns keeps a stale entry. When that netns is later<br /> destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a<br /> slab-use-after-free reported by KASAN, followed by a kernel BUG at<br /> net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify().<br /> <br /> Reachable from an unprivileged user namespace (unshare --user<br /> --map-root-user --net).<br /> <br /> ip6gre_changelink() earlier in the same file already uses the cached<br /> t-&gt;net; only ip6erspan_changelink() has the wrong shape.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: Fix slab-out-of-bounds access in auth message processing<br /> <br /> If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY<br /> contains a positive value in its result field, it is treated as an<br /> error code by ceph_handle_auth_reply() and returned to<br /> handle_auth_reply(). Thereafter, an attempt is made to send the<br /> preallocated message of type CEPH_MSG_AUTH, where the returned value is<br /> interpreted as the size of the front segment to send. If the result<br /> value in the message is greater than the size of the memory buffer<br /> allocated for the front segment, an out-of-bounds access occurs, and<br /> the content of the memory region beyond this buffer is sent out.<br /> <br /> This patch fixes the issue by treating only negative values in the<br /> result field as errors. Positive values are therefore treated as success<br /> in the same way as a zero value. Additionally, a BUG_ON is added to<br /> __send_prepared_auth_request() comparing the len parameter to<br /> front_alloc_len to prevent sending the message if it exceeds the bounds<br /> of the allocation and to make it easier to catch any logic flaws leading<br /> to this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pseries/papr-hvpipe: Fix null ptr deref in papr_hvpipe_dev_create_handle()<br /> <br /> commit 6d3789d347a7 ("papr-hvpipe: convert papr_hvpipe_dev_create_handle() to FD_PREPARE()"),<br /> changed the create handle to FD_PREPARE(), but it caused kernel<br /> null-ptr-deref because after call to retain_and_null_ptr(src_info),<br /> src_info is re-used for adding it to the global list.<br /> <br /> Getting the following kernel panic in papr_hvpipe_dev_create_handle()<br /> when trying to add src_info to the list.<br /> Kernel attempted to write user page (0) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on write at 0x00000000<br /> Faulting instruction address: 0xc0000000001b44a0<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> ...<br /> Call Trace:<br /> papr_hvpipe_dev_ioctl+0x1f4/0x48c (unreliable)<br /> sys_ioctl+0x528/0x1064<br /> system_call_exception+0x128/0x360<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> Now, the error handling with FD_PREPARE&amp;#39;s file cleanup and __free(kfree) auto<br /> cleanup is getting too convoluted. This is mainly because we need to<br /> ensure only 1 user get the srcID handle. To simplify this, we allocate<br /> prepare the src_info in the beginning and add it to the global list<br /> under a spinlock after checking that no duplicates exist.<br /> <br /> This simplify the error handling where if the FD_ADD fails, we can<br /> simply remove the src_info from the list and consume any pending msg in<br /> hvpipe to be cleared, after src_info became visible in the global list.