CVE-2026-53398

What it actually does

This flaw affects the Linux kernel NFS server implementation, specifically NFSD handling of the NFSv4 SECINFO_NO_NAME operation. When a malformed or truncated XDR RPC request is decoded, the error path can release a stale, previously used export pointer because the field is not initialized before a failable decode step. That can corrupt kernel memory through an invalid reference release, potentially causing a kernel panic, use-after-free behavior, denial of service, or—in the worst case depending on kernel build, memory layout, and exploitability—privileged code execution in kernel context. The CVSS vector indicates network-reachable, unauthenticated exploitation with no user interaction if NFSD is exposed.

Why it matters to the business

Organizations running Linux systems that provide NFSv4 file-sharing services could experience unexpected server crashes, loss of file-service availability, or broader host compromise if the memory corruption is made reliably exploitable. The risk is highest for NFS servers reachable from untrusted networks or large internal networks. Although this vulnerability is not currently listed in CISA KEV, has no known ransomware association, and has low EPSS at the time of assessment, the high CVSS score and unauthenticated network attack surface make patching important for systems running NFSD.

How an attack unfolds

An attacker first identifies a Linux host exposing the NFS service, typically on TCP or UDP port 2049, and confirms NFSv4 support. The attacker then sends a crafted NFSv4 COMPOUND RPC containing a SECINFO_NO_NAME operation with a deliberately truncated XDR payload so that decoding fails after some operation state has been partially processed. Because the vulnerable kernel path may not initialize the associated export pointer before the failure, the error cleanup routine can operate on stale contents left from a previous RPC operation. This can cause an invalid exp_put() on the stale pointer, leading to kernel memory corruption. In practical attacks, the most likely immediate outcome is an NFSD worker failure or kernel crash; advanced exploitation may attempt to shape kernel memory state through repeated RPC traffic to turn the bug into controlled corruption.

How to fix it

Apply the vendor-provided Linux kernel update that includes the NFSD fix initializing the SECINFO_NO_NAME export pointer before any failable decode operation. No universal fixed kernel version was provided in the input, so use the fixed kernel package from the relevant Linux distribution or appliance vendor. Reboot into the patched kernel after installation and verify the active running kernel is the updated one. Where immediate patching is not possible, reduce exposure by disabling the NFS server if not required, disabling NFSv4 if operationally feasible, restricting access to port 2049 to trusted clients only, blocking NFS at network boundaries, and monitoring for malformed NFSv4 traffic. Avoid exposing NFS services directly to the Internet.

How to confirm the fix worked

Confirm whether the system is acting as an NFS server by checking for active nfsd kernel threads, exported file systems, and listeners on TCP or UDP port 2049. Validate remediation by confirming the running kernel package includes the vendor fix for this issue and that the host has been rebooted into that kernel. Review distribution security advisories or kernel changelogs for the NFSD SECINFO_NO_NAME decode cleanup fix. From a network perspective, verify that only approved clients can reach NFS services. From a stability perspective, confirm kernel logs no longer show NFSD crashes, bad XDR handling anomalies, KASAN reports, general protection faults, or stack traces referencing nfsd4_decode_secinfo_no_name, nfsd4_secinfo_no_name_release, or exp_put after patching.

Typical attack path

1. Scan for hosts exposing NFS on TCP or UDP port 2049.
2. Confirm the service supports NFSv4 and accepts unauthenticated RPC requests to NFSD.
3. Send normal or semi-valid NFSv4 COMPOUND operations to influence reusable NFSD per-request state.
4. Send a malformed or truncated NFSv4 SECINFO_NO_NAME request that triggers a bad XDR decode path.
5. Trigger vulnerable cleanup where NFSD releases a stale export pointer from a previous operation.
6. Cause kernel memory corruption, service instability, kernel panic, or potentially kernel-level code execution if exploitation is reliable.

How to detect it

To determine whether this was already exploited, review kernel logs, system journal entries, crash dumps, and centralized logging from Linux NFS servers for NFSD crashes or memory-corruption symptoms. Useful sources include /var/log/kern.log, /var/log/messages, journalctl -k output, kdump/vmcore data, audit logs, EDR kernel telemetry, firewall logs, NetFlow, and packet captures for port 2049. Look for repeated NFS bad XDR errors, NFSv4 COMPOUND traffic containing SECINFO_NO_NAME, abrupt nfsd worker failures, kernel Oops or panic messages, KASAN use-after-free reports, general protection faults, or stack traces containing nfsd4_decode_secinfo_no_name, nfsd4_secinfo_no_name_release, or exp_put. Network indicators are likely to be weak because malformed RPC payloads may not be logged by default; correlate suspicious NFS traffic bursts from a single client with kernel instability or reboots. No public exploitation, named threat actor activity, or ransomware use was provided in the input, so prioritize anomaly-based detection rather than actor-specific hunting.

• nfsd4_decode_secinfo_no_name
• nfsd4_secinfo_no_name_release
• exp_put
• SECINFO_NO_NAME
• NFS4ERR_BADXDR
• nfserr_bad_xdr
• bad XDR
• nfsd: non-standard errno
• KASAN: use-after-free
• BUG: KASAN
• Oops:
• kernel BUG
• general protection fault
• Unable to handle kernel NULL pointer dereference
• nfsd
• port 2049
• TCP/2049
• UDP/2049
• NFSv4 COMPOUND
• 00000034

What your security team should do

• Inventory Linux systems exposing NFS, especially NFSv4, on TCP or UDP port 2049.
• Prioritize patching Internet-facing, DMZ, shared storage, virtualization, backup, and high-dependency NFS servers.
• Apply vendor kernel updates and reboot systems into the fixed kernel; live patching should only be considered sufficient if the vendor explicitly covers this NFSD fix.
• Restrict NFS access to known client IP ranges using host firewalls, security groups, network ACLs, or segmentation controls.
• Disable unused NFS services or NFSv4 functionality where business requirements allow.
• Add detections for kernel crash logs and NFSD stack traces involving SECINFO_NO_NAME, bad XDR decode failures, nfsd4_secinfo_no_name_release, and exp_put.
• Review network telemetry for unusual or repeated NFSv4 COMPOUND requests, especially malformed requests followed by service instability.
• Do not treat the low EPSS and lack of KEV listing as a reason to defer remediation on exposed NFS servers because exploitation is unauthenticated and network reachable.