CVE-2021-47366 in Linux
Summary
by MITRE • 05/21/2024
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server
AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and Linux's afs client switches between them when talking to a non-YFS server if the read size, the file position or the sum of the two have the upper 32 bits set of the 64-bit value.
This is a problem, however, since the file position and length fields of FS.FetchData are *signed* 32-bit values.
Fix this by capturing the capability bits obtained from the fileserver when it's sent an FS.GetCapabilities RPC, rather than just discarding them, and then picking out the VICED_CAPABILITY_64BITFILES flag. This can then be used to decide whether to use FS.FetchData or FS.FetchData64 - and also FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to switch on the parameter values.
This capabilities flag could also be used to limit the maximum size of the file, but all servers must be checked for that.
Note that the issue does not exist with FS.StoreData - that uses *unsigned* 32-bit values. It's also not a problem with Auristor servers as its YFS.FetchData64 op uses unsigned 64-bit values.
This can be tested by cloning a git repo through an OpenAFS client to an OpenAFS server and then doing "git status" on it from a Linux afs client[1]. Provided the clone has a pack file that's in the 2G-4G range,
the git status will show errors like:
error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
This can be observed in the server's FileLog with something like the following appearing:
Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001 Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866 ... Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5
Note the file position of 18446744071815340032. This is the requested file position sign-extended.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 05/13/2025
The vulnerability described in CVE-2021-47366 affects the Linux kernel's OpenAFS client implementation and represents a critical data corruption issue that occurs when reading files within the 2GB to 4GB address range from OpenAFS servers. This flaw specifically impacts the AFS-3 protocol's data fetch operations where the client must choose between two RPC variants: FS.FetchData and FS.FetchData64. The issue stems from the Linux kernel's afs client implementation incorrectly determining which RPC variant to use based on the upper 32 bits of 64-bit file position and length values. When these values exceed the 32-bit signed integer range, the client incorrectly selects the FS.FetchData variant, which uses signed 32-bit fields that cannot properly represent large file positions. This results in sign extension of the file position value, causing data corruption and read errors that manifest as packfile mismatches during git operations. The vulnerability demonstrates a fundamental flaw in protocol compatibility handling where the client fails to properly negotiate server capabilities before making critical RPC calls, leading to data integrity issues that can compromise the entire file system operation.
The technical root cause of this vulnerability lies in the client's decision-making process for RPC variant selection, which relies on the upper 32 bits of 64-bit values rather than proper capability negotiation. Specifically, the Linux afs client performs a bitwise check using upper_32_bits() to determine whether to use FS.FetchData or FS.FetchData64, but this approach fails when dealing with large file positions that exceed the signed 32-bit range. The FS.FetchData RPC variant uses signed 32-bit fields for both file position and length, which causes sign extension issues when the upper bits are set, while FS.FetchData64 correctly uses 64-bit unsigned values. This design flaw creates a scenario where legitimate large file operations are incorrectly routed through the 32-bit variant, resulting in corrupted data reads. The vulnerability also highlights a lack of proper capability discovery and utilization within the client implementation, where the client receives capability information from the server during FS.GetCapabilities RPC but fails to properly store and utilize the VICED_CAPABILITY_64BITFILES flag that indicates server support for 64-bit file operations.
The operational impact of this vulnerability extends beyond simple data corruption to potentially compromise entire git repository operations and file system consistency when working with large files in the 2GB to 4GB range. When users perform git operations such as git status on repositories cloned through OpenAFS clients, they encounter specific error messages indicating packfile mismatches that occur because the client reads corrupted data from the server. The server logs show the problematic file positions with values that are sign-extended 64-bit addresses, clearly demonstrating how the signed 32-bit fields in FS.FetchData cause the corruption. This vulnerability affects systems using OpenAFS servers that are not YFS-compatible, particularly older OpenAFS implementations that do not support the unsigned 64-bit fetch operations. The impact is particularly severe for development environments and version control systems that frequently handle large binary files or repository packfiles in the specified address range. The vulnerability also affects systems where file operations span large file boundaries, making it a persistent issue rather than a one-time occurrence, and can lead to data loss or repository corruption that requires manual recovery processes.
The mitigation strategy for this vulnerability requires implementing proper capability negotiation within the Linux afs client by capturing and utilizing the VICED_CAPABILITY_64BITFILES flag obtained during the FS.GetCapabilities RPC exchange. This approach ensures that the client makes informed decisions about which RPC variants to use based on actual server capabilities rather than heuristic checks of upper 32-bit values. The fix involves modifying the client code to store the capability bits received from the server and then use this information to determine whether to employ FS.FetchData or FS.FetchData64, as well as FS.StoreData or FS.StoreData64, for all file operations. This change aligns with established security practices for protocol implementation where proper capability negotiation should always be used instead of heuristic approaches that can lead to security vulnerabilities or data corruption. Additionally, the fix should include checks to limit maximum file sizes based on server capabilities, though this requires broader compatibility testing across different server implementations. The solution addresses the underlying design flaw by implementing proper state management of server capabilities and ensures that file operations maintain data integrity regardless of file position or size, making it compliant with industry standards for secure protocol implementation and reducing the attack surface for similar issues. This vulnerability demonstrates the importance of capability-based protocol design and proper error handling in distributed file systems, aligning with ATT&CK techniques related to privilege escalation through protocol manipulation and data integrity compromise.