CVE-2022-48829 in Linux
Summary
by MITRE • 07/16/2024
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes
iattr::ia_size is a loff_t, so these NFSv3 procedures must be careful to deal with incoming client size values that are larger than s64_max without corrupting the value.
Silently capping the value results in storing a different value than the client passed in which is unexpected behavior, so remove the min_t() check in decode_sattr3().
Note that RFC 1813 permits only the WRITE procedure to return NFS3ERR_FBIG. We believe that NFSv3 reference implementations also return NFS3ERR_FBIG when ia_size is too large.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2025
The vulnerability described in CVE-2022-48829 affects the Linux kernel's Network File System version 3 implementation, specifically within the NFSD (NFS server daemon) component. This issue manifests in how the NFSv3 SETATTR and CREATE procedures handle file size parameters, creating a potential vector for data corruption and unexpected behavior in distributed file systems. The problem stems from the improper handling of large file size values that exceed the maximum signed 64-bit integer limit, which can lead to incorrect file size storage and potentially compromise file system integrity.
The technical flaw resides in the decode_sattr3() function where a min_t() check was previously implemented to cap incoming file size values that exceed s64_max. This approach silently truncates large file size parameters, causing the system to store a different value than what the client originally specified. Since iattr::ia_size is defined as a loff_t (large offset type) data structure, it is designed to handle large file sizes, but the kernel's implementation failed to properly validate and process these values. This behavior violates the expected NFSv3 protocol semantics where clients should be able to specify file sizes without unexpected truncation, potentially leading to data loss or corruption when large files are created or modified.
The operational impact of this vulnerability extends beyond simple data corruption, as it affects the reliability and consistency of NFSv3 file operations across networked systems. When large file sizes are silently capped, clients may experience unexpected behavior where file operations succeed but result in different file sizes than anticipated, potentially causing applications that depend on precise file size information to malfunction. The vulnerability also represents a deviation from RFC 1813 standards, which explicitly permits only the WRITE procedure to return NFS3ERR_FBIG error codes for file size violations. This misalignment with established NFS specifications can lead to interoperability issues between different NFS implementations and create inconsistencies in error handling across networked storage environments.
The resolution to CVE-2022-48829 involves removing the problematic min_t() check from the decode_sattr3() function, allowing large file size values to be properly processed according to NFSv3 protocol expectations. This change ensures that when file sizes exceed the maximum signed 64-bit integer limit, the system handles these values appropriately rather than silently truncating them. From a cybersecurity perspective, this fix addresses potential data integrity issues that could be exploited in scenarios where malicious actors might attempt to manipulate file sizes to trigger unexpected behavior or create denial of service conditions. The mitigation aligns with CWE-191, which deals with Integer Underflow (Wrap or Wraparound) and CWE-190, which covers Integer Overflow and Wraparound, both of which are relevant to the improper handling of large integer values in this context. This vulnerability also relates to ATT&CK technique T1499.001, which involves File System Wipe, as improper file size handling could potentially contribute to data loss scenarios in networked file systems, though the direct impact is more focused on data integrity rather than malicious deletion.