GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux fuse io-uring: request headers copied from a non-whitelisted slab object panics hardened usercopy

UnscoredCVE-2026-80946Kernel, userspace & hypervisorcurated

Impact

The fuse-io-uring transport copies req->in.h and req->out.h directly between userspace and the fuse_request slab object, whose cache has no usercopy whitelist. On kernels built with CONFIG_HARDENED_USERCOPY the check fires and the kernel BUGs, taking the node down. Any unprivileged user who can mount or talk to a FUSE filesystem over the io-uring transport can reach it, which matters on GPU nodes that run FUSE-backed object storage or dataset mounts inside tenant pods - a single tenant can panic a host that is expensive to drain and reboot. Without hardened usercopy the same copies read and write slab memory outside a declared whitelist.

Who can reach it

Local user able to drive a FUSE filesystem over the io-uring transport - in practice any tenant workload with a FUSE mount (dataset cache, object-store gateway) in its container. No special privilege beyond access to the FUSE device or mount is described.

What to do

Apply the stable kernel update carrying the bounce-buffer fix and reboot each node; the fix is in fs/fuse, so a reboot is required. Until then, disabling the fuse io-uring transport (or not exposing FUSE mounts to untrusted tenants) removes the path without a reboot.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.