CVE-2021-47366

What it actually does

The Linux kernel AFS client incorrectly selects the signed 32-bit FS.FetchData RPC instead of FS.FetchData64 for file positions or lengths in the 2G-4G range when communicating with non-YFS OpenAFS servers, causing sign-extension of the position value and subsequent data corruption on read.

Why it matters to the business

Organizations using Linux clients to access OpenAFS servers may experience silent data corruption in files between 2 GB and 4 GB, leading to application errors, failed integrity checks, and potential loss of work in large repositories or datasets.

How an attack unfolds

An attacker or benign user triggers a read of a file whose position or size causes the upper 32 bits to be set; the client sends a sign-extended position to the server via FS.FetchData, the server returns incorrect data, and the client writes corrupted content locally. No special privileges are required beyond normal AFS read access.

How to fix it

Upgrade the Linux kernel to a version containing the fix that captures VICED_CAPABILITY_64BITFILES and uses it to select the appropriate 64-bit RPCs for both fetch and store operations.

How to confirm the fix worked

Confirm the presence of the capability-handling change in the afs filesystem code and test by performing git clone and status operations on a repository whose pack file resides in the 2G-4G range against an OpenAFS server.

Typical attack path

1. Mount an AFS volume from a non-YFS OpenAFS server on a vulnerable Linux client
2. Perform a read operation on a file whose offset or length has bits set above 2^31
3. Client selects FS.FetchData due to upper_32_bits() check and passes sign-extended position
4. Server processes the malformed request and returns incorrect file data
5. Client stores the corrupted data, manifesting as application-level errors such as packfile mismatches

How to detect it

Examine kernel logs and application logs for AFS FetchData errors, unexpected sign-extended file positions near 18446744071815340032, or repeated integrity-check failures on files in the 2-4 GB range; review server FileLog entries showing SRXAFS_FetchData returns with anomalous position values.

What your security team should do

• Prioritize kernel updates on all systems that mount AFS volumes from OpenAFS servers
• Monitor for application errors indicating packfile or data-integrity mismatches after large-file reads
• Consider migrating to YFS/Auristor servers that are unaffected by the signed-value limitation