CVE-2021-46952

What it actually does

Invalid 'retrans' mount option value (>=64) supplied for UDP NFS transport triggers an unchecked left-shift on a 64-bit integer in xprt_calc_majortimeo(), producing an out-of-bounds memory access.

Why it matters to the business

Local users on systems exposing NFS-over-UDP mounts can trigger kernel crashes or memory corruption, leading to denial of service and potential information disclosure on affected Linux hosts.

How an attack unfolds

An attacker with local access supplies a malicious retrans value through the mount syscall or /etc/fstab for an NFS-UDP share; the kernel passes the unchecked value into the shift calculation, causing the out-of-bounds access.

How to fix it

Upgrade to a Linux kernel containing the upstream fix that validates retrans < 64 for UDP transports before the shift; rebuild and reboot affected systems; avoid UDP for NFS when possible or enforce strict mount-option filtering.

How to confirm the fix worked

Confirm kernel source or binary contains the retrans bounds check; attempt a mount with retrans=64 and verify the operation is rejected with an error rather than triggering a shift fault.

Typical attack path

1. Obtain local shell or mount privileges on the target host
2. Issue a crafted nfs mount command or fstab entry specifying UDP transport and retrans >= 64
3. Kernel invokes xprt_calc_majortimeo() with the garbage value
4. Shift operation exceeds 63 bits, producing memory corruption or oops

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for shift-out-of-bounds warnings or oopses referencing xprt_calc_majortimeo or NFS UDP retrans; correlate with mount syscalls containing retrans values >=64.

• shift out-of-bounds in xprt_calc_majortimeo
• NFS: retrans option value too large
• invalid retransmission timeout

What your security team should do

• Patch all hosts to a kernel with the retrans validation fix as soon as vendor packages are available
• Audit fstab and automation for explicit UDP NFS mounts and convert to TCP where feasible
• Add kernel module or LSM policy to restrict unprivileged mount options if immediate patching is delayed