CVE-2026-33179

What it actually does

CVE-2026-33179 is a local denial-of-service flaw in libfuse 3.18.0 through versions before 3.18.2, limited to the io_uring transport path. During FUSE io_uring queue initialization, fuse_uring_init_queue can continue after numa_alloc_local fails, leaving NULL pointers that may later be dereferenced. A related error path in fuse_uring_register_queue can leak NUMA-backed allocations while incorrectly reporting success. A local user able to exercise the affected FUSE/io_uring code path can crash the FUSE daemon or repeatedly trigger memory/resource exhaustion. Confidentiality and integrity are not directly impacted, and the traditional /dev/fuse path is not affected.

Why it matters to the business

Systems relying on affected libfuse versions with the io_uring transport enabled may experience local service disruption, crashes of FUSE-backed filesystems, degraded application availability, or resource exhaustion. This is most relevant to Linux environments where user-accessible FUSE mounts support application workflows, development platforms, containerized workloads, desktop integrations, backup tools, or storage abstractions. The CVSS score indicates moderate severity, EPSS is very low and stable, there is no known CISA KEV listing, and no ransomware use is reported; however, local multi-user systems and shared compute hosts should still prioritize patching because a low-privileged user can affect availability.

How an attack unfolds

An attacker first needs local access to a Linux system running an affected libfuse version and a way to invoke or interact with a FUSE daemon using the io_uring transport. The attacker then triggers the vulnerable queue initialization or registration failure path, for example by forcing allocation or registration failure conditions during io_uring queue setup. In affected versions, the code may proceed after a failed NUMA allocation, resulting in a NULL pointer dereference and daemon crash. Alternatively, a failed queue registration can leak memory while still being treated as successful, allowing repeated attempts to exhaust resources. Successful exploitation results in denial of service against the FUSE daemon or the services depending on the mounted filesystem, not remote code execution.

How to fix it

Upgrade libfuse to version 3.18.2 or later wherever libfuse 3.18.0 or 3.18.1 is deployed. If packages are provided by a Linux distribution, apply the vendor’s patched libfuse/libfuse3 package rather than relying only on upstream version numbers, because distributions may backport fixes. If immediate patching is not possible, disable or avoid the libfuse io_uring transport and use the traditional /dev/fuse path where operationally feasible. Restrict local shell access and FUSE mount privileges to trusted users, especially on shared systems. Monitor memory pressure and FUSE daemon restarts until patched.

How to confirm the fix worked

Confirm installed libfuse versions using package inventory and runtime checks such as distribution package metadata for libfuse3/libfuse, or libfuse library version reporting where available. Exposure is most likely when versions are 3.18.0 or 3.18.1 and the io_uring transport is enabled or used by FUSE daemons. Validate remediation by confirming the installed package includes the upstream 3.18.2 fix or a vendor backport addressing fuse_uring_init_queue and fuse_uring_register_queue error handling. Where safe, reproduce pre-patch regression tests in a non-production environment and confirm io_uring queue setup failure paths no longer crash the daemon or leak memory. Also confirm that FUSE-backed services remain stable after upgrade and that no repeated crash loops are present in system logs.

Typical attack path

1. Obtain local, low-privileged access to a Linux system using libfuse 3.18.0 or 3.18.1.
2. Identify or create a FUSE workload that uses the libfuse io_uring transport rather than the traditional /dev/fuse path.
3. Trigger io_uring queue initialization or registration under conditions that cause NUMA allocation or queue registration failure.
4. Cause fuse_uring_init_queue to dereference NULL pointers, crashing the FUSE daemon, or cause fuse_uring_register_queue to leak allocations.
5. Repeat the trigger as needed to keep the FUSE-backed service unavailable or to increase local memory/resource pressure.

How to detect it

To determine whether this issue may already have been exploited, review host logs for FUSE daemon crashes, service restart loops, segmentation faults, out-of-memory events, and unexplained memory growth around FUSE workloads using io_uring. Relevant sources include systemd journal logs, syslog, kernel logs, audit logs, crash dumps, coredumpctl records, service manager restart history, endpoint telemetry, and resource monitoring data. Look for crashes or core dumps involving FUSE daemons, libfuse, io_uring initialization, or references to fuse_uring_init_queue/fuse_uring_register_queue. In development or instrumented environments, AddressSanitizer or LeakSanitizer output referencing NULL pointer dereference or leaked NUMA allocations is especially relevant. Because exploitation requires local access, correlate crashes with recent local logins, new FUSE mounts, new user-run FUSE processes, suspicious repeated mount attempts, or resource exhaustion events caused by unprivileged users. No public threat actors or active campaigns are currently associated with this issue based on the provided data.

• fuse_uring_init_queue
• fuse_uring_register_queue
• numa_alloc_local
• io_uring
• AddressSanitizer: SEGV
• AddressSanitizer:DEADLYSIGNAL
• LeakSanitizer: detected memory leaks
• NULL pointer dereference
• segfault at 0
• libfuse.so
• fusermount3
• fusermount
• mount.fuse
• systemd-coredump
• Out of memory: Killed process
• oom-kill
• Failed with result 'core-dump'

What your security team should do

• Inventory Linux systems and images for libfuse/libfuse3 versions 3.18.0 and 3.18.1, including containers, appliances, and developer workstations.
• Prioritize patching shared Linux hosts, multi-user systems, CI runners, VDI/desktops, container hosts, and storage/application servers that allow untrusted or semi-trusted local users.
• Upgrade to libfuse 3.18.2 or a vendor-backported fixed package; rebuild dependent images or packages that bundle vulnerable libfuse versions.
• If patching is delayed, disable or avoid the io_uring transport for libfuse workloads and limit FUSE usage to trusted users.
• Add monitoring for FUSE daemon crashes, repeated service restarts, kernel or systemd OOM events, and unusual memory growth in FUSE-related processes.
• Review local access controls and remove unnecessary shell access, FUSE mount permissions, or user namespace patterns that let low-privileged users create disruptive FUSE workloads.
• Because EPSS is low, exploit maturity is listed as none, and there is no KEV listing, treat this as a controlled availability-risk patch rather than an emergency internet-facing incident unless local untrusted users are present.