CVE-2026-53391

What it actually does

This is a Linux kernel client-side denial-of-service vulnerability in the NFSv4 pNFS flexfile code path. When a pNFS-capable client processes a crafted GETDEVICEINFO response from a malicious or compromised NFS metadata server, the kernel decoder can accept a zero-length r_addr field, leave the decoded buffer as NULL, and then call strrchr() on that NULL pointer. The result is a kernel NULL pointer dereference that can panic or crash the affected client system. The flaw does not directly provide code execution, data disclosure, or privilege escalation, but it can remotely impact availability of clients that mount NFSv4 pNFS/flexfile shares from an attacker-controlled or compromised server.

Why it matters to the business

An attacker who controls or compromises an NFS metadata server can crash Linux systems that mount affected pNFS/flexfile exports, causing service outages, failed workloads, interrupted batch jobs, and potential loss of availability for applications relying on those clients. The operational risk is highest for environments using NFSv4 pNFS/flexfile for shared storage, compute clusters, virtualization hosts, container nodes, or high-performance storage workflows. Although EPSS is currently low and there is no known KEV listing or ransomware association, the vulnerability is network-reachable in the affected configuration and requires no authentication to the client beyond the client connecting to a malicious or compromised server.

How an attack unfolds

An attacker first needs to position a malicious NFSv4 metadata server, compromise a legitimate NFS metadata server, or otherwise cause a vulnerable Linux client to mount and communicate with an attacker-controlled pNFS/flexfile service. During normal pNFS operation, the client requests device layout information using GETDEVICEINFO. The malicious server replies with a malformed multipath data-server address structure where the r_addr opaque field has zero length. The vulnerable kernel path decodes the field, receives a success return with a NULL buffer, and then attempts to parse the address using strrchr() without validating that the buffer is non-NULL. This triggers a NULL pointer dereference in kernel context, likely resulting in an oops or full kernel panic depending on system panic settings. The attacker’s practical objective is denial of service against the NFS client.

How to fix it

Apply Linux kernel updates from the relevant distribution or kernel vendor that include the fix to reject zero-length r_addr values in nfs4_decode_mp_ds_addr() and treat the malformed GETDEVICEINFO body as -EBADMSG. No exact fixed package versions were provided, so use vendor advisories and package changelogs to identify the backported fix for CVE-2026-53391. Where immediate patching is not possible, reduce exposure by disabling pNFS/flexfile use where feasible, mounting only from trusted NFS servers, restricting NFS access with network controls, preventing clients from mounting untrusted exports, and monitoring for unexpected NFS metadata servers. General NFS hardening such as segmentation, firewall allowlisting, and strict server identity management can reduce the likelihood of clients encountering malicious GETDEVICEINFO responses, but patching the kernel is the definitive remediation.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix by checking distribution security advisories, kernel package changelogs, or source/backport references for the nfs4_decode_mp_ds_addr() zero-length r_addr validation change. Verify that affected systems have rebooted into the patched kernel, not merely installed the package. Inventory systems using NFSv4 pNFS/flexfile mounts and confirm whether pNFS is enabled or required. Validate mitigation by ensuring clients only mount approved NFS servers and by reviewing mount options and network policy. In test environments, a malformed GETDEVICEINFO response with a zero-length r_addr should be rejected as a bad message rather than causing a kernel oops or panic.

Typical attack path

1. Identify Linux clients using NFSv4 pNFS/flexfile mounts or lure/redirect a client to an attacker-controlled NFSv4 metadata server.
2. Serve or compromise an NFSv4 metadata server that can respond to pNFS GETDEVICEINFO requests.
3. Wait for the client to request device information for a pNFS/flexfile layout.
4. Return a crafted GETDEVICEINFO multipath data-server address containing a zero-length r_addr opaque value.
5. Trigger the vulnerable nfs4_decode_mp_ds_addr() parsing path on the client.
6. Cause a kernel NULL pointer dereference and crash or panic the affected client, creating a denial-of-service condition.

How to detect it

To determine whether exploitation may have occurred, review client-side kernel logs and crash artifacts rather than server application logs alone, because the failure occurs inside the Linux kernel NFS client. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, kdump/vmcore data, crash dumps, system reboot records, NFS client telemetry, and network captures around NFSv4 GETDEVICEINFO traffic. Look for kernel oops or panic events involving NULL pointer dereference, NFSv4, pNFS, flexfile, GETDEVICEINFO, or the function nfs4_decode_mp_ds_addr(). Correlate crashes with recent NFS mount activity, new or changed NFS metadata servers, DNS/routing changes for NFS endpoints, or unusual NFSv4 server responses. If packet capture is available, inspect NFSv4 GETDEVICEINFO replies for malformed multipath data-server address structures or zero-length r_addr opaque fields. Because exploit maturity is currently reported as none and the vulnerability is not KEV-listed, detection should focus on crash forensics and anomalous NFS server behavior rather than known public exploit signatures.

• BUG: kernel NULL pointer dereference
• kernel NULL pointer dereference
• Oops:
• Kernel panic
• nfs4_decode_mp_ds_addr
• strrchr
• GETDEVICEINFO
• NFSv4
• pNFS
• pnfs
• flexfile
• malformed GETDEVICEINFO
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Prioritize patching Linux systems that act as NFSv4 pNFS/flexfile clients, especially shared compute, storage-dependent application, virtualization, and container hosts.
• Inventory NFSv4 mounts and identify where pNFS/flexfile is enabled or negotiated.
• Restrict NFS client access to approved metadata servers using firewall rules, routing controls, security groups, or equivalent network allowlists.
• Disable pNFS/flexfile where it is not operationally required until affected kernels are patched.
• Review kernel logs for recent NULL pointer dereferences, NFSv4/pNFS errors, or panics occurring during NFS mount or layout/device discovery operations.
• Confirm all patched systems have been rebooted into the updated kernel.
• Track vendor advisories for exact fixed kernel package versions because fixed versions were not supplied in the input.
• Treat unexplained crashes of NFS clients connected to untrusted or recently changed NFS servers as potentially suspicious and preserve logs for investigation.