CVE-2026-53392

What it actually does

This is a Linux kernel availability vulnerability in the NFSv4 pNFS flexfiles client code. When decoding a flexfiles layout, the kernel failed to reject a filehandle-version array count of zero. That zero value can result in a zero-size allocation sentinel being stored where later code expects at least one valid filehandle version. Subsequent NFS layout return/update paths can dereference invalid memory and trigger a kernel oops or panic. The impact is denial of service: a vulnerable client system can crash when it processes a malformed flexfiles layout from an NFSv4/pNFS source. No confidentiality or integrity impact is indicated.

Why it matters to the business

Systems that use affected Linux kernels as NFSv4/pNFS flexfiles clients could be remotely crashed by malformed NFS layout data, causing application downtime, interrupted file access, failed jobs, or node reboots. The risk is most relevant to environments that mount NFS shares from less-trusted, compromised, or externally reachable NFS infrastructure. This issue is not listed in CISA KEV, has no known ransomware association, and has a low EPSS score, but it is a kernel-level network-triggered denial-of-service flaw and should still be prioritized for systems that rely on NFS for production workloads.

How an attack unfolds

An attacker needs a vulnerable Linux system to process a malicious NFSv4/pNFS flexfiles layout. In a practical scenario, the attacker operates a malicious NFS server, compromises a legitimate NFS server, or positions themselves where they can influence NFSv4 layout responses. When the client requests or receives flexfiles layout metadata, the attacker returns a malformed layout body with a zero filehandle-version count. The vulnerable kernel accepts that zero count and stores an invalid zero-size allocation result. Later, when the client performs layout return or layout update handling, kernel code assumes at least one filehandle version exists and dereferences invalid memory. This can produce a KASAN null-pointer dereference, kernel oops, or full kernel panic, resulting in denial of service for the affected host.

How to fix it

Apply vendor kernel updates that include the fix rejecting fh_count == 0 in the NFSv4 flexfiles layout parser. Because no product-specific fixed versions were provided, track the advisory from the Linux distribution or appliance vendor supplying the kernel and update to the first fixed kernel release or later. Where immediate patching is not possible, reduce exposure by avoiding mounts from untrusted NFS servers, restricting NFS access to trusted networks, disabling or avoiding NFSv4.1+ pNFS/flexfiles functionality where operationally feasible, using NFS versions or mount configurations that do not use pNFS flexfiles, and blacklisting or not loading the flexfiles layout driver if it is not required. Treat these mitigations as temporary; the durable remediation is a patched kernel.

How to confirm the fix worked

Confirm that affected systems are running a kernel build that contains the upstream fix for NFSv4/flexfiles zero filehandle-version count validation or a vendor backport of that fix. Validate package status with the operating system vendor’s kernel changelog, advisory, or package metadata rather than relying only on the displayed upstream kernel version, because distributions often backport security fixes. On systems that do not require pNFS flexfiles, confirm that flexfiles layout support is disabled or not loaded. Where safe test infrastructure exists, mount a controlled NFSv4/pNFS test export and verify that malformed flexfiles layouts with fh_count=0 are rejected without a kernel oops, KASAN report, or panic, while valid layouts continue to open, read, and unmount normally.

Typical attack path

1. Identify Linux systems that mount NFSv4.1 or later exports using pNFS flexfiles layouts.
2. Gain control of, impersonate, or influence an NFS server or NFS traffic path used by the client.
3. Send a malformed flexfiles layout response containing a zero filehandle-version count.
4. Wait for the client to process the malformed layout and later perform layout update or layout return handling.
5. Trigger invalid kernel memory access, causing an oops, panic, reboot, or loss of service.

How to detect it

Look for evidence of kernel crashes or near-crashes on Linux systems that use NFSv4/pNFS flexfiles. Primary sources include kernel logs, journald, syslog, dmesg output, crash dumps, kdump/vmcore artifacts, hypervisor reset records, endpoint telemetry, and storage/NFS access logs. Search for call traces involving ff_layout_alloc_lseg, ff_layout_encode_ff_layoutupdate, ff_layout_encode_layoutreturn, nfs4_xdr_enc_layoutreturn, flexfiles, pnfs, or layoutreturn shortly before a reboot or panic. A likely exploitation or testing artifact is a null-pointer dereference or KASAN report in the NFS flexfiles layout path, followed by an oops or kernel panic. Network evidence may include NFSv4.1+ layout operations from a client to an unexpected or newly changed NFS server, especially LAYOUTGET, GETDEVICEINFO, or LAYOUTRETURN traffic around the time of a crash. Because the failure occurs in kernel memory handling, detection is primarily behavioral and crash-log based; absence of a durable on-disk artifact does not rule out exploitation.

• KASAN: null-ptr-deref
• Kernel panic - not syncing: Fatal exception
• ff_layout_alloc_lseg
• ff_layout_encode_ff_layoutupdate
• ff_layout_encode_layoutreturn
• nfs4_xdr_enc_layoutreturn
• NFSv4/flexfiles
• flexfiles
• LAYOUTRETURN
• GETDEVICEINFO
• LAYOUTGET
• pnfs
• nfs_layout_flexfiles

What your security team should do

• Inventory Linux systems that mount NFSv4.1+ or pNFS/flexfiles exports, especially production servers, compute nodes, storage clients, and appliances using vendor kernels.
• Prioritize patching NFS client systems that mount shares from shared, multi-tenant, cross-zone, externally managed, or otherwise less-trusted NFS servers.
• Restrict NFS traffic to approved clients and servers using host firewalls, network ACLs, storage network segmentation, and export controls.
• Temporarily avoid pNFS/flexfiles or untrusted NFS mounts on systems that cannot be patched promptly.
• Monitor kernel logs and crash telemetry for NFS flexfiles call traces, KASAN null-pointer dereferences, oopses, and panics involving layout return/update functions.
• Review NFS server trust boundaries and investigate any unexpected NFS servers, DNS changes, mount target changes, or network paths capable of influencing client layout responses.
• Because this is not currently KEV-listed and has low EPSS, align urgency with NFS exposure: high for active NFSv4/pNFS clients, lower for systems that do not use NFS client functionality.