CVE-2026-53392 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
NFSv4/flexfiles: reject zero filehandle version count
ff_layout_alloc_lseg() decodes the filehandle-version array count from the flexfiles layout body. The value is used as the count for kzalloc_objs(), and the current code only rejects NULL.
A zero count yields ZERO_SIZE_PTR, which can be stored in dss_info->fh_versions even though later flexfiles paths assume that at least one filehandle version exists.
Reject fh_count == 0 before the allocation, matching the existing zero version_count validation in the flexfiles GETDEVICEINFO parser.
A QEMU/KASAN run with a malformed flexfiles layout hit:
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
RIP: 0010:ff_layout_encode_ff_layoutupdate.isra.0+0x15f/0x750 ff_layout_encode_layoutreturn+0x683/0x970 nfs4_xdr_enc_layoutreturn+0x278/0x3a0 Kernel panic - not syncing: Fatal exception
The patched kernel rejects the malformed layout without KASAN/oops/panic, and a valid fh_count=1 regression still opens, reads, and unmounts cleanly.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability exists within the Linux kernel's NFSv4/flexfiles implementation where the ff_layout_alloc_lseg() function processes filehandle-version array counts from flexfiles layout bodies. The flaw occurs when the function decodes a version count value that is used as an argument to kzalloc_objs() for memory allocation purposes. The original code only validated against NULL values but failed to reject zero counts which result in ZERO_SIZE_PTR being returned by the kernel's memory allocator. This problematic pointer can subsequently be stored in dss_info->fh_versions despite later flexfiles code paths making assumptions that at least one filehandle version must exist, creating a fundamental inconsistency in the data structure validation process.
The technical impact of this vulnerability manifests through a null pointer dereference condition that occurs during kernel memory operations. When a malformed flexfiles layout contains a zero filehandle version count, the system allocates a ZERO_SIZE_PTR which then gets stored in the filehandle versions structure. During subsequent processing, particularly when encoding layout updates or handling layout returns, the code attempts to access this invalid pointer leading to a kernel panic and system crash. The KASAN (Kernel Address Sanitizer) report shows the exact location of failure at ff_layout_encode_ff_layoutupdate where it attempts to dereference memory at address range 0x0000000000000010-0x0000000000000017, demonstrating a classic null pointer access pattern that leads to system termination.
This vulnerability directly maps to CWE-476 which describes Null Pointer Dereference conditions in software implementations. The flaw represents a validation gap in the flexfiles GETDEVICEINFO parser where existing code properly validates version_count against zero values but fails to apply the same validation to the filehandle count parameter during layout allocation. From an operational perspective, this represents a critical security risk that could be exploited by malicious actors to cause denial of service attacks against NFSv4 servers or clients, potentially leading to complete system crashes and unavailability of network file services. The vulnerability affects systems running Linux kernels with NFSv4/flexfiles support where remote attackers can craft malformed flexfiles layouts to trigger the exploitable condition.
The mitigation strategy involves implementing proper input validation before memory allocation occurs, specifically rejecting fh_count == 0 values in the ff_layout_alloc_lseg() function prior to calling kzalloc_objs(). This approach aligns with the existing validation patterns already present in the flexfiles GETDEVICEINFO parser and ensures that all code paths maintain consistent assumptions about filehandle version count requirements. The patch effectively prevents malformed layouts from being processed further, eliminating the risk of kernel panics while maintaining compatibility with valid flexfiles operations. Systems should be updated to patched kernel versions that implement this validation check, ensuring that both the immediate vulnerability is resolved and the broader NFSv4/flexfiles subsystem maintains robust input sanitization practices. The regression testing performed demonstrates that valid filehandle counts of 1 continue to operate correctly through all phases of file operations including open, read, and unmount processes, confirming that the fix does not impact legitimate functionality while addressing the exploitable condition.