CVE-2026-33179: libfuse DOS Vulnerability

CVE-2026-33179 Overview

CVE-2026-33179 is a Null Pointer Dereference vulnerability affecting libfuse, the reference implementation of the Linux FUSE (Filesystem in Userspace) interface. This vulnerability exists in versions 3.18.0 to 3.18.1 and allows a local user to crash the FUSE daemon or cause resource exhaustion through improper error handling in the fuse_uring_init_queue function.

When numa_alloc_local fails during io_uring queue entry setup, the code proceeds with NULL pointers, leading to a crash. Additionally, when fuse_uring_register_queue fails, NUMA allocations are leaked and the function incorrectly returns success, causing resource exhaustion over time. Only the io_uring transport is affected; the traditional /dev/fuse path remains unaffected.

Critical Impact

Local attackers can crash the FUSE daemon or exhaust system resources, leading to denial of service conditions for any applications relying on FUSE-mounted filesystems.

Affected Products

• libfuse version 3.18.0
• libfuse version 3.18.1
• Systems using io_uring transport with libfuse (traditional /dev/fuse path is not affected)

Discovery Timeline

• 2026-03-20 - CVE CVE-2026-33179 published to NVD
• 2026-03-23 - Last updated in NVD database

Technical Details for CVE-2026-33179

Vulnerability Analysis

The vulnerability resides in the fuse_uring_init_queue function within lib/fuse_uring.c. This function is responsible for initializing io_uring queue entries for high-performance FUSE operations. The flaw manifests in two distinct failure scenarios:

1. NULL Pointer Dereference: When numa_alloc_local fails to allocate memory during io_uring queue entry setup, the function does not properly handle the failure and continues execution with NULL pointers. Subsequent operations on these NULL pointers cause the FUSE daemon to crash.

2. Memory Leak: When fuse_uring_register_queue fails after NUMA allocations have been made, the allocated memory is not freed before the function returns. Furthermore, the function incorrectly returns success (0) instead of an error code, allowing the calling code to believe initialization succeeded while resources remain leaked.

The vulnerability was confirmed using AddressSanitizer (ASan) and LeakSanitizer (LSan), memory debugging tools that detected both the NULL dereference and the memory leak conditions.

Root Cause

The root cause is improper error handling in the fuse_uring_init_queue function. Specifically, the error path incorrectly jumped to an err label that would fall through to return success, rather than immediately returning the error code. This design flaw meant that failures in io_uring initialization were not properly propagated to callers, and allocated resources were leaked.

Attack Vector

This is a local attack vector requiring the attacker to have local access to a system running a FUSE daemon with io_uring transport enabled. The attacker can trigger the vulnerability by:

1. Causing memory allocation failures through resource exhaustion or NUMA allocation constraints
2. Repeatedly triggering failed queue initializations to leak memory over time
3. Exploiting race conditions during FUSE daemon startup or reconfiguration

The attack results in denial of service through either an immediate crash (NULL dereference) or gradual resource exhaustion (memory leak).

// Security patch from lib/fuse_uring.c - Fix for NULL deref and memory leak
 	if (res != 0) {
 		fuse_log(FUSE_LOG_ERR, "qid=%d io_uring init failed\n",
 			 queue->qid);
-		goto err;
+		return res;
 	}
 
 	queue->req_header_sz = ROUND_UP(sizeof(struct fuse_ring_ent),

Source: GitHub Commit Update

The patch changes the error handling from using a goto err statement (which would fall through incorrectly) to immediately returning the error code, ensuring proper error propagation and preventing resource leaks.

Detection Methods for CVE-2026-33179

Indicators of Compromise

• Unexpected FUSE daemon crashes with segmentation fault signals
• Gradual memory consumption increase in FUSE daemon processes
• Application failures when accessing FUSE-mounted filesystems
• System logs showing FUSE io_uring initialization errors

Detection Strategies

• Monitor FUSE daemon process stability and crash events using process monitoring tools
• Track memory usage trends for processes using libfuse with io_uring transport
• Implement AddressSanitizer builds in development/staging environments to catch NULL dereferences
• Review system logs for io_uring init failed error messages from FUSE daemons

Monitoring Recommendations

• Configure alerts for FUSE daemon process crashes or restarts
• Set up memory usage thresholds for FUSE-related processes
• Monitor /var/log/syslog or journal for FUSE error messages
• Implement regular libfuse version audits to ensure patched versions are deployed

How to Mitigate CVE-2026-33179

Immediate Actions Required

• Upgrade libfuse to version 3.18.2 or later immediately
• If upgrade is not immediately possible, disable io_uring transport and use traditional /dev/fuse path
• Monitor affected systems for signs of denial of service or resource exhaustion
• Review application dependencies to identify all systems using affected libfuse versions

Patch Information

The vulnerability has been fixed in libfuse version 3.18.2. The patch modifies the error handling in fuse_uring_init_queue to immediately return error codes rather than falling through to incorrect success returns. The fix is available in commit 7beb86c09b6ec5aab14dc25256ed8a5ad18554d7.

For detailed patch information, refer to the GitHub Security Advisory and the libfuse 3.18.2 Release Notes.

Workarounds

• Disable io_uring transport for FUSE operations by using traditional /dev/fuse interface
• Implement resource limits (ulimits) on FUSE daemon processes to contain memory leak impact
• Deploy process monitoring and automatic restart capabilities for critical FUSE daemons
• Restrict local access to systems running vulnerable FUSE configurations

# Configuration example - Disable io_uring transport for FUSE operations
# When mounting FUSE filesystems, use traditional transport
# Check if your FUSE application supports disabling io_uring

# Monitor FUSE daemon memory usage
ps aux | grep fuse | awk '{print $2, $6}'

# Set memory limits for FUSE processes (example with systemd)
# In your FUSE service unit file, add:
# MemoryLimit=512M
# Restart=on-failure