Linux kernel FUSE: slab out-of-bounds write in fuse_dev_do_write when the retrieve length is truncated

Impact

When the byte count to retrieve is clamped to fc->max_pages and an offset is present, fuse_dev_do_write() runs past the end of the folio array - a syzkaller-reported slab out-of-bounds write. This is the interesting one in this batch for GPU clouds: FUSE is how most of them mount object storage and dataset caches onto nodes (s3fs, gcsfuse, JuiceFS, FUSE-based CSI drivers), and the write side of /dev/fuse is driven by the userspace filesystem daemon. Anyone able to serve a FUSE device - including an unprivileged user where unprivileged FUSE mounts are permitted - can drive a controlled heap write in kernel context, which is a credible local privilege escalation on a shared node.

Who can reach it

Local: requires the ability to write to a /dev/fuse connection, i.e. to run a FUSE server. On nodes allowing unprivileged or in-container FUSE mounts (a frequent setting for dataset mounts), that is any tenant with a pod; otherwise it is limited to the service account running the storage daemon.

What to do

Update to a stable kernel with the added loop termination check (two backports linked in the record) and reboot each node - FUSE is in-kernel, so there is no userspace workaround short of rebuilding the module. Where a reboot cannot be scheduled immediately, deny unprivileged FUSE mounts to tenant pods (drop the device from the container, do not grant SYS_ADMIN or the fuse device plugin) so the write path is reachable only by trusted storage daemons. No fixed release number is given.

References

Related entries

• Linux kernel i40e: wrong dev_id in free_irq() leaves IRQs un-freed on the MSI-X error pathCVE-2025-39911 · Linux kernel i40e driver (Intel X710/XL710 MSI-X IRQ request error path)High
• Linux kernel BPF: missing destination length check in bpf_crypto_crypt allows out-of-bounds writeCVE-2025-39917 · Linux kernel BPF (bpf_crypto_crypt dynptr length check)High
• Linux kernel io_uring: io_link_skb compares a notification against itself, skipping the context validation checkCVE-2025-39963 · Linux kernel io_uring zero-copy send (io_link_skb notification context check)High
• Linux kernel (net/xfrm): SPI 0 means 'no SPI assigned', but the duplicate-SPI rework started creating states with SPI 0CVE-2025-39965 · Linux kernel (net/xfrm)High
• Linux kernel (drivers/iommu/iommufd): Aborting an iommufd object allocation freed the object immediately while theCVE-2025-39966 · Linux kernel (drivers/iommu/iommufd)High
• Linux kernel mlx5_core flow steering / flow counters (hardware steering): Use-after-free releasingCVE-2025-39979 · Linux kernel mlx5_core flow steering / flow counters (hardware steering)High