CVE-2022-24448

What it actually does

nfs_atomic_open returns uninitialized kernel data in the file descriptor instead of ENOTDIR when O_DIRECTORY is set on a regular file during NFS lookup.

Why it matters to the business

Local processes may receive leftover kernel memory contents, creating a minor risk of sensitive data exposure on systems using NFS; low urgency given age and limited scope.

How an attack unfolds

A local attacker writes or runs an application that opens a regular file on an NFS mount while forcing the O_DIRECTORY flag; nfs_atomic_open performs a lookup, the server fails to enforce the directory check, and uninitialized data leaks back into the returned file descriptor.

How to fix it

Update the Linux kernel to a version containing commit ab0fc21bc7105b54bafd85bd8b82742f9e68898a or later; rebuild and reboot affected systems; verify the NFS client code no longer returns uninitialized data on this code path.

How to confirm the fix worked

Confirm the running kernel contains commit ab0fc21bc7105b54bafd85bd8b82742f9e68898a; test by attempting to open a regular file with O_DIRECTORY on an NFS mount and verifying ENOTDIR is returned without data leakage.

Typical attack path

1. Locate an NFS-mounted filesystem
2. Craft or execute a local program that opens a regular file with O_DIRECTORY
3. Trigger nfs_atomic_open via the VFS layer
4. Read the returned file descriptor to obtain uninitialized kernel memory

How to detect it

Review application and system logs for unusual O_DIRECTORY usage on NFS paths; inspect kernel audit records or strace output for open calls returning unexpected data; no widespread exploitation indicators reported.

What your security team should do

• Prioritize kernel updates on all systems mounting NFS exports
• Audit local applications that set O_DIRECTORY when opening paths
• Monitor for future Linux kernel NFS fixes and apply promptly