CVE-2024-38626

What it actually does

Race condition in FUSE request handling allows FR_SENT flag to remain set when requests are re-queued to the pending list via FUSE_NOTIFY_RESEND, causing fuse_request_end to trigger warnings on duplicate processing of the same request.

Why it matters to the business

Systems relying on FUSE-based filesystems may experience kernel warnings, potential request handling instability, and require urgent patching on affected Linux kernels to maintain operational reliability.

How an attack unfolds

An attacker with access to the FUSE device issues a sequence of read and write syscalls: first reading an INIT request (setting FR_SENT), then sending a FUSE_NOTIFY_RESEND to re-queue it, followed by an invalid-address read that forces premature request termination and triggers the warning path.

How to fix it

Upgrade affected Linux kernels to commit 533070db659a9589310a743e9de14cf9d651ffaf or later; apply equivalent fixes to eclipse-threadx/threadx at 39f3c86c61ec478720bac9fca8f17ccedb8f052b.

How to confirm the fix worked

Verify kernel source contains the FR_SENT clearing logic in the request resend path; test with reproducer sequences that previously triggered fuse_request_end warnings; confirm no duplicate processing warnings appear under FUSE_NOTIFY_RESEND load.

Typical attack path

1. Open FUSE device and issue fuse_dev_read to fetch INIT request
2. Issue fuse_dev_write with FUSE_NOTIFY_RESEND to move request back to pending list without clearing FR_SENT
3. Issue fuse_dev_read with invalid output address to force copy failure and call fuse_request_end
4. Observe kernel warning in logs from duplicate request handling

How to detect it

Search kernel logs and dmesg for the exact warning string from fuse_request_end at fs/fuse/dev.c:300; correlate with processes performing rapid fuse_dev_read and fuse_dev_write sequences involving FUSE_NOTIFY_RESEND.

• WARNING: CPU.*fuse_request_end.*fs/fuse/dev.c:300
• fuse_dev_do_read.*FUSE_NOTIFY_RESEND
• FR_SENT bit set on re-queued request

What your security team should do

• Prioritize kernel upgrades on all systems exposing FUSE devices within 30 days
• Monitor kernel logs for fuse_request_end warnings as immediate detection signal
• Restrict untrusted access to /dev/fuse until patches are deployed