CVE-2026-46256

What it actually does

This Linux kernel flaw can cause an availability failure when NFS LOCALIO is used for loopback-style NFS access on the same system. LOCALIO optimizes NFS READ, WRITE, and COMMIT operations by bypassing the network when the NFS client and server are local to the same host, but page-cache allocations could occur in a filesystem reclaim path that re-enters NFS writeback through nfs_writepages. Under memory pressure or crafted local I/O activity, this can create recursive direct reclaim behavior and deadlock the kernel I/O path. The practical technical result is a local denial of service: affected systems may hang, stall NFS/XFS writeback, report blocked kernel tasks, or require reboot to recover. The CVSS vector indicates local access with low complexity and low privileges is required, with no confidentiality or integrity impact but high availability impact.

Why it matters to the business

The main business risk is service disruption on Linux systems using NFS LOCALIO or local NFS loopback configurations, especially where NFS-backed workloads, fileservers, virtualization hosts, build systems, or storage-heavy applications depend on sustained writeback performance. A successful trigger can cause application hangs, filesystem stalls, or host unavailability, potentially requiring operational intervention or reboot. This vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a very low EPSS score, so broad internet-driven exploitation is unlikely; however, the impact can still be material for multi-user Linux systems or environments where untrusted local users or workloads can generate heavy filesystem activity.

How an attack unfolds

An attacker needs local code execution or an account capable of performing filesystem operations on an affected Linux system. The target system must be running a vulnerable kernel and using an NFS LOCALIO scenario where the NFS client and server are determined to be on the same host. The attacker then generates memory pressure and write-heavy filesystem activity through the LOCALIO-backed NFS mount. During direct memory reclaim, the kernel can enter filesystem writeback paths that recurse back into NFS via nfs_writepages. Because vulnerable kernels do not consistently allocate LOCALIO page-cache memory from GFP_NOFS context, reclaim can re-enter filesystem code in a way that creates a deadlock. Once triggered, affected tasks can become stuck in uninterruptible sleep, NFS or XFS writeback can stall, and the host may become partially or fully unavailable until the condition clears or the system is rebooted.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for NFS LOCALIO page-cache allocations using GFP_NOFS context. No exact fixed package versions were provided in the input, so use the fixed kernel packages from the relevant Linux distribution vendor or backport advisory rather than relying only on upstream version numbers. Prioritize systems using NFS LOCALIO, NFS loopback mounts, local NFS server/client combinations, or storage-heavy workloads. If immediate patching is not possible, reduce exposure by disabling or avoiding NFS LOCALIO where supported, removing unnecessary loopback NFS mounts, limiting local shell or workload access to trusted users, reducing untrusted write-heavy activity on NFS mounts, and monitoring for blocked kernel tasks or writeback stalls. Because this is a kernel-level availability issue, configuration mitigations should be treated as temporary until patched kernels are deployed.

How to confirm the fix worked

Confirm exposure by inventorying Linux kernel versions and checking vendor advisories for whether the running kernel includes the NFS LOCALIO GFP_NOFS fix. Review NFS mount configurations and kernel/module settings to determine whether LOCALIO or same-host NFS loopback behavior is in use. After remediation, verify that the system is booted into the patched kernel, not merely that the package is installed. Confirm with uname, package-manager kernel metadata, and distribution-specific changelogs. Functional validation should include controlled NFS writeback and memory-pressure testing in a non-production environment to confirm the system no longer shows blocked tasks, reclaim recursion, or nfs_writepages stalls. Avoid attempting aggressive denial-of-service reproduction on production systems.

Typical attack path

1. Obtain local, low-privileged access to a Linux system running an affected kernel.
2. Identify or rely on an NFS loopback or LOCALIO-enabled configuration where NFS client and server are on the same system.
3. Generate sustained write-heavy I/O through the affected NFS mount.
4. Create or amplify memory pressure so the kernel enters direct reclaim while handling LOCALIO page-cache allocations.
5. Trigger recursive reclaim/writeback behavior involving NFS writepages and the underlying filesystem.
6. Cause kernel task stalls, I/O deadlock, service degradation, or host unavailability.

How to detect it

Detecting prior exploitation is difficult because the flaw causes a kernel deadlock rather than producing a distinctive payload, file, process, or network artifact. Focus on system and kernel telemetry around the time of service degradation. Review journalctl, dmesg, /var/log/kern.log, /var/log/messages, and distribution-specific system logs for blocked kernel tasks, hung task detector output, NFS writeback stalls, direct reclaim activity, XFS writeback involvement, and stack traces containing nfs_writepages or LOCALIO-related functions. Correlate these events with local user sessions, cron jobs, batch jobs, containers, or processes that generated heavy writes to NFS mounts and with signs of memory pressure such as OOM activity, high direct reclaim, or prolonged uninterruptible I/O waits. Also review authentication logs and process accounting, if available, for local users or jobs active immediately before the hang. There are no known public exploit-specific indicators, no KEV listing, and no known ransomware association, so detection should emphasize behavioral correlation rather than signature-only matching.

• nfs_writepages
• LOCALIO
• localio
• blocked for more than 120 seconds
• hung_task_timeout_secs
• INFO: task
• task blocked for more than
• D state
• uninterruptible sleep
• direct reclaim
• GFP_NOFS
• NFS:
• xfs:
• writeback
• kswapd
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• dmesg

What your security team should do

• Inventory Linux systems using NFS, especially same-host NFS client/server or LOCALIO-style loopback configurations.
• Prioritize kernel patching for systems with local multi-user access, container workloads, build farms, storage servers, virtualization hosts, or other write-heavy workloads.
• Track distribution vendor advisories and deploy the first kernel update that explicitly includes the NFS LOCALIO direct reclaim deadlock fix.
• If patching is delayed, disable or avoid NFS LOCALIO and remove unnecessary loopback NFS mounts where operationally feasible.
• Restrict local access and workload placement on affected systems so untrusted users or jobs cannot intentionally generate heavy NFS writeback and memory pressure.
• Enable or tune kernel hung-task, NFS, filesystem, and system health monitoring to alert on blocked tasks, uninterruptible I/O waits, and writeback stalls.
• Prepare operational recovery procedures for affected hosts, including safe service restart and reboot decision criteria if kernel-level deadlock occurs.
• Because the vulnerability is not KEV-listed, not known ransomware-used, and has low EPSS, treat it as targeted operational-risk remediation rather than an emergency internet-exposed remote-code-execution event.