CVE-2026-80946

What it actually does

The FUSE io-uring transport copies fuse_request in/out headers (req->in.h / req->out.h) directly between an unwhitelisted fuse_request SLUB object (fuse_req_cachep) and userspace. With CONFIG_HARDENED_USERCOPY this is treated as illegal kernel-memory exposure and aborts in usercopy_abort(), causing a kernel BUG/Oops and host panic. Without hardened usercopy, the same path can disclose fuse_request slab contents into the io_uring ring. Impact is local denial of service (availability) and, on non-hardened kernels, potential kernel heap disclosure. No privilege escalation or remote code execution is indicated.

Why it matters to the business

A local process that uses FUSE over io_uring can crash the entire host, interrupting all workloads on that node until reboot. EPSS is very low (~0.002) and unchanged over 30 days, the issue is not in CISA KEV, it is not associated with ransomware, and exploit maturity is none about 20 days after publication—so this is a standard kernel availability patch, not an emergency internet-facing incident. Risk is highest on multi-tenant, CI, and developer systems that allow unprivileged FUSE and io_uring; locked-down hosts that do not use that path are largely unaffected.

How an attack unfolds

An attacker with local unprivileged execution on a Linux host that permits FUSE and io_uring drives FUSE operations over the io-uring transport so the kernel copies request headers out of (and back into) the fuse_request slab object toward the shared ring. Because that slab cache is not usercopy-whitelisted, hardened usercopy detects the copy, calls usercopy_abort(), and panics the kernel. No memory corruption or privilege gain is required; reaching fuse_uring_copy_to_ring / fuse_uring_commit is enough to take the node offline. On kernels without hardened usercopy, the same copy can leak kernel slab data into userspace-visible ring memory. No named threat actors or in-the-wild campaigns are associated with this issue.

How to fix it

Install a kernel that includes the fix which bounces FUSE io-uring request headers through an on-stack buffer so usercopy touches stack memory rather than the fuse_request slab object (the 'fuse: copy request headers via a stack buffer for io-uring' change). Follow your distribution's kernel security advisory for the exact package version; no per-package fixed versions were supplied with this record. Until patched, restrict unprivileged FUSE and io_uring (policy, seccomp, sysctl, and user-namespace controls) on multi-tenant hosts and avoid FUSE io-uring workloads.

How to confirm the fix worked

Confirm the running kernel changelog or distro CVE mapping includes this FUSE io-uring header bounce, or that fs/fuse/dev_uring.c copies headers via a stack buffer in the send/commit path rather than directly from the slab object. Inventory hosts with FUSE and io_uring enabled. After patching, run a controlled FUSE io-uring workload in a non-production environment and verify kernel logs show no usercopy_abort or 'fuse_request' SLUB exposure Oops. Unpatched kernels with CONFIG_HARDENED_USERCOPY remain crash-prone if that path is reachable.

Typical attack path

1. Obtain local unprivileged code execution on a Linux host that allows FUSE and io_uring
2. Open or use a FUSE filesystem via the io-uring transport
3. Cause the kernel to copy FUSE request in/out headers between the fuse_request slab object and the ring
4. Hardened usercopy rejects the unwhitelisted slab copy and panics the kernel
5. Host becomes unavailable until reboot (DoS)

How to detect it

This issue typically leaves an obvious kernel Oops rather than stealthy persistence. Search dmesg, journalctl -k, serial/console logs, kdump/vmcore, and panic pipelines for HARDENED_USERCOPY aborts naming SLUB object 'fuse_request', usercopy_abort, and FUSE io-uring frames (copy_header_to_ring, fuse_uring_prepare_send, fuse_uring_send_in_task) under io_uring_enter / task_work. Correlate crashes with processes using FUSE and io_uring. Absence of these logs does not prove non-exploitation on kernels without CONFIG_HARDENED_USERCOPY, where the copy may leak slab data without panicking. No named APT activity is reported.

• usercopy: Kernel memory exposure attempt detected from SLUB object 'fuse_request'
• usercopy: Kernel memory exposure attempt detected from SLUB object 'fuse_request' (offset 56, size 40)
• kernel BUG at mm/usercopy.c
• usercopy_abort
• copy_header_to_ring
• fuse_uring_prepare_send
• fuse_uring_send_in_task
• fuse_uring_copy_to_ring
• fs/fuse/dev_uring.c
• __check_heap_object

What your security team should do

• Patch Linux kernels that ship FUSE io-uring, prioritizing multi-tenant, CI, and developer hosts
• Until patched, limit unprivileged FUSE and io_uring via policy and host hardening
• Hunt kernel logs and crash dumps for the fuse_request usercopy abort signature
• Track distro kernel advisories for the exact fixed package; this record has no version list
• Treat as a local DoS kernel fix (low EPSS, not KEV, no ransomware use)—not an internet-facing emergency