CVE-2021-47167

What it actually does

Failure to reset the mirror array in nfs_pageio_error_cleanup() and reliance on pg_count instead of list emptiness in nfs_pageio_do_add_request() leaves the NFS page I/O structure in an inconsistent state that can trigger a kernel oops or memory corruption during subsequent operations.

Why it matters to the business

Unexpected system crashes or instability on Linux servers using NFS, leading to service outages, potential data loss during I/O, and unplanned downtime for affected workloads.

How an attack unfolds

An attacker with local access triggers error paths in NFS page I/O operations, such as network disruptions or malformed requests, causing the kernel to dereference stale mirror array pointers and panic the system.

How to fix it

Update to a Linux kernel version that includes the fix for the NFS page I/O mirror array reset and list-empty check; apply the latest stable kernel from your distribution.

How to confirm the fix worked

Verify the running kernel contains the commit resolving the nfs_pageio_error_cleanup and nfs_pageio_do_add_request changes; test NFS error paths in a lab environment to confirm no oops occurs.

Typical attack path

1. Obtain local user access on a Linux system using NFS
2. Induce NFS page I/O errors through network manipulation or file operations
3. Trigger __nfs_pageio_add_request() without proper cleanup of the mirror array
4. Cause kernel oops via use of invalid state in nfs_pageio_do_add_request()

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for NFS page I/O related oops or panic entries; correlate with NFS mount activity and error conditions.

What your security team should do

• Prioritize kernel updates on all NFS client and server systems within standard patch cycles
• Monitor kernel logs for NFS-related oops messages as an interim detection measure
• Limit NFS exposure to trusted networks until patches are applied