CVE-2026-46005

What it actually does

This is a local Linux kernel availability flaw in the XFS filesystem DAX handling path. When xfs_alloc_buftarg() encounters an error, the kernel fails to release a DAX device reference with fs_put_dax(), causing a resource leak. A local user who can trigger the affected XFS/DAX error path may repeatedly consume kernel/device references until system resources are exhausted or filesystem/device operations degrade, potentially leading to denial of service. The issue does not provide known confidentiality or integrity impact and requires local access with low privileges according to the provided CVSS vector.

Why it matters to the business

Systems using affected Linux kernels with XFS and DAX-capable storage configurations may be exposed to local denial-of-service risk. Successful exploitation could disrupt applications that rely on the affected host, cause operational instability, require service restarts or host reboots, and create availability incidents. The current EPSS score is very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so broad active exploitation is not currently indicated; however, kernel availability bugs should still be prioritized on shared, multi-user, virtualized, high-availability, or storage-intensive systems.

How an attack unfolds

An attacker first obtains local access to a Linux system running an affected kernel. They then identify whether XFS and DAX-backed storage paths are present or can be exercised. By repeatedly triggering operations that cause xfs_alloc_buftarg() to enter its error path, the attacker causes DAX device references to be leaked instead of released. Over time, repeated triggering can exhaust relevant kernel or device resources, destabilize storage operations, or force administrative recovery actions such as unmounting filesystems, restarting services, or rebooting the system. There is no indication from the provided data that this flaw enables remote code execution, privilege escalation, data theft, or ransomware activity.

How to fix it

Upgrade the Linux kernel to a vendor-provided version that includes the XFS fix adding fs_put_dax() cleanup in the xfs_alloc_buftarg() error path. No exact fixed package versions were provided, so use the relevant distribution or appliance vendor advisory to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users and workloads, avoiding use of DAX on XFS where not required, applying workload isolation, and monitoring systems that combine XFS with DAX-capable persistent memory or direct-access storage. Rebooting may be required after kernel updates or to clear leaked resources on already affected systems.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version is at or above the fixed version identified by the operating system vendor, not merely that an updated package is installed on disk. Review vendor changelogs or kernel source patches for the XFS change that releases the DAX reference in the xfs_alloc_buftarg() error path. Validate exposure by inventorying systems using XFS and DAX-capable storage and checking whether they run affected kernel builds. After patching and rebooting, monitor kernel logs and system resource behavior during XFS/DAX mount and error-handling scenarios to confirm that repeated operations no longer cause progressive resource leakage or instability.

Typical attack path

1. Gain local access to a Linux system running an affected kernel.
2. Determine whether XFS filesystems and DAX-capable storage paths are available or can be targeted.
3. Trigger XFS/DAX allocation failures that exercise the xfs_alloc_buftarg() error path.
4. Repeat the operation to accumulate unreleased DAX device references.
5. Cause resource exhaustion, degraded filesystem behavior, kernel instability, or denial of service.
6. Wait for dependent services or the host to fail, hang, or require administrative recovery.

How to detect it

There are no reliable public exploit-specific indicators from the provided data. Detection should focus on host-based evidence of attempted or successful denial of service involving XFS and DAX paths. Review kernel logs, system journal entries, audit logs, and EDR telemetry for repeated XFS mount or device errors, repeated access to DAX-backed XFS filesystems by the same local user or process, abnormal growth in kernel resource usage, filesystem hangs, storage timeouts, or system instability preceding a reboot. Useful log sources include /var/log/kern.log, /var/log/messages, journalctl -k output, auditd records for mount/unmount activity, sudo/session logs for local users, and EDR process telemetry around scripts or binaries repeatedly exercising filesystem operations. Because exploitation is local, correlate suspicious filesystem activity with interactive logins, container workloads, cron jobs, CI jobs, or untrusted user sessions. Absence of these artifacts does not prove non-exploitation, especially if logs rolled over or the host was rebooted after resource exhaustion.

• xfs_alloc_buftarg
• fs_put_dax
• DAX
• XFS
• journalctl -k
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory Linux systems using XFS filesystems, especially those with DAX, persistent memory, or direct-access storage configurations.
• Prioritize kernel updates for multi-user systems, shared compute platforms, storage servers, and production hosts where local denial of service would be operationally significant.
• Track distribution-specific advisories to identify the exact fixed kernel package because no fixed versions were provided in the input.
• Restrict local access to trusted users and workloads until patching is complete.
• Where feasible, disable or avoid DAX on XFS systems that do not require it as a temporary risk reduction measure.
• After patching, reboot affected systems to ensure the fixed kernel is active and to clear any leaked runtime references.
• Monitor kernel logs and availability metrics for repeated XFS/DAX errors, mount failures, device-reference anomalies, hangs, or unexplained resource exhaustion.
• Treat evidence of repeated XFS/DAX error triggering by an untrusted local user as suspicious activity even though no public exploitation is currently reported.