CVE-2026-53397

What it actually does

This vulnerability is a memory leak in the Linux kernel NFS server ACL handling path. When an NFS ACL SETACL request is decoded, the kernel may successfully allocate and attach an access ACL, then fail while decoding the default ACL. On that decode-failure path, the normal request handler is skipped and the previous release routine did not free the already allocated posix_acl object. A remote, unauthenticated attacker that can reach the NFS service can repeatedly send malformed SETACL RPC requests to leak kernel memory over time, potentially exhausting memory and causing service degradation, NFS server instability, or host-level denial of service. The issue affects availability only; it does not directly provide data disclosure, privilege escalation, or code execution.

Why it matters to the business

Organizations exposing Linux NFS services to untrusted or broad networks could experience outages or severe performance degradation if attackers or misconfigured clients repeatedly trigger the leak. The likely operational impact is loss of file-sharing availability for applications, users, build systems, virtualization platforms, or other workloads that depend on NFS. Although this issue is not currently listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, the vulnerability is network-reachable, low-complexity, and requires no authentication, so Internet-exposed or widely reachable NFS servers should be prioritized for patching.

How an attack unfolds

An attacker first identifies a host running the Linux kernel NFS server with NFS ACL support reachable over the network. They then send crafted NFS ACL SETACL RPC requests where decoding of the first ACL succeeds but decoding of the second ACL fails. Because the vulnerable release path does not free the first allocated posix_acl object after decode failure, each request leaves a small amount of kernel memory permanently allocated for the lifetime of the NFS server. By repeating the malformed request many times, the attacker incrementally consumes kernel memory. At sufficient volume or duration, this can produce memory pressure, degraded NFS performance, failed allocations, service instability, or a broader system denial of service.

How to fix it

Upgrade the Linux kernel to a version that includes the fix for the NFS server SETACL release path. The fix introduces dedicated release handlers for ACLPROC2_SETACL and ACLPROC3_SETACL that free both access and default ACL objects on all svc_process paths, including decode failure. If exact vendor fixed versions are not available, apply the latest security-supported kernel from the operating system vendor or distribution. Where immediate patching is not possible, reduce exposure by disabling NFS service if not required, blocking NFS and rpcbind access from untrusted networks, restricting access with host firewalls and network ACLs, limiting NFS to trusted management or application subnets, and monitoring memory usage on NFS servers closely. Avoid exposing NFS directly to the Internet.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or kernel build includes the upstream fix for the nfsd SETACL ACL release handlers. Validate that the system has rebooted into the patched kernel, not merely installed it. Review distribution advisories or changelogs for references to the nfsd posix_acl leak, nfsaclsvc_release_setacl, or nfs3svc_release_setacl. Confirm NFS exposure by checking listening services for rpcbind and nfsd and ensuring access is limited to trusted sources. Where safe and authorized, use a controlled test environment to send malformed SETACL decode-failure requests and verify that repeated requests do not cause sustained kernel memory growth. In production, validate indirectly by confirming patch level, service exposure, and stable memory behavior under normal NFS workload.

Typical attack path

1. Scan for systems exposing NFS-related RPC services, commonly rpcbind on TCP/UDP 111 and nfsd on TCP/UDP 2049.
2. Confirm that the target is a Linux NFS server with ACL-related procedures reachable.
3. Send malformed NFS ACL SETACL requests designed to pass the first ACL decode and fail the second ACL decode.
4. Repeat the malformed requests to accumulate leaked posix_acl allocations in kernel memory.
5. Continue until the NFS service or host experiences memory pressure, degraded performance, failed allocations, or denial of service.

How to detect it

Detection should focus on signs of attempted or successful denial-of-service activity against Linux NFS servers. Review network telemetry, firewall logs, NetFlow, packet captures, and IDS data for repeated connections or datagrams to rpcbind and NFS ports, especially TCP/UDP 111 and TCP/UDP 2049, from unexpected sources. Look for unusually high rates of NFS ACL SETACL RPC calls or malformed RPC requests if RPC-aware logging or packet inspection is available. On hosts, review kernel logs, system journals, NFS server logs, and monitoring data for unexplained memory growth, slab/cache growth, allocation failures, OOM killer activity, nfsd worker instability, or NFS service degradation without a corresponding workload increase. Because the vulnerability is a kernel memory leak on a decode-failure path, exploitation may not leave a clean application log entry; absence of logs does not rule out exploitation. If suspected, preserve kernel logs, memory metrics, NFS service status, recent network flow records, and packet captures covering traffic to NFS-related ports.

• tcp/111
• udp/111
• tcp/2049
• udp/2049
• rpcbind
• nfsd
• SETACL
• ACLPROC2_SETACL
• ACLPROC3_SETACL
• nfsaclsvc_decode_setaclargs
• nfs3svc_decode_setaclargs
• posix_acl
• Out of memory
• oom-killer
• invoked oom-killer
• nfsd:
• /proc/slabinfo
• /proc/meminfo

What your security team should do

• Identify Linux systems running kernel NFS server services, especially those listening on TCP/UDP 2049 or registered through rpcbind on TCP/UDP 111.
• Prioritize patching NFS servers that are Internet-facing, accessible from user networks, shared across multiple business-critical workloads, or difficult to restart during an outage.
• Upgrade to the latest vendor-supported kernel containing the NFS SETACL memory leak fix and reboot into the patched kernel.
• If patching is delayed, restrict NFS and rpcbind access to explicitly trusted client IP ranges using host firewalls, network firewalls, and security groups.
• Disable NFS ACL functionality or the NFS server where it is not required, if supported and operationally safe.
• Monitor NFS servers for abnormal kernel memory growth, slab growth, OOM activity, nfsd instability, and spikes in malformed or failed RPC activity.
• Review network telemetry for repeated NFS ACL SETACL-like traffic from untrusted or unexpected sources.
• Treat sustained unexplained memory pressure on exposed NFS servers as potentially suspicious until patched and investigated.