Linux kernel SUNRPC: sysfs read of an RPC transport can oops when the socket is torn down concurrently

CVSS 4.7CVE-2022-48816Kernel, userspace & hypervisorcurated

Impact

Reading the RPC transport attributes under sysfs does not hold ->recv_mutex, so ->sock can be set to NULL underneath the reader and the kernel dereferences it. The result is a host oops. An earlier fix (commit 17f09d3f619a) only narrowed the race window rather than closing it, which is why a second fix was needed. This is relevant to GPU fleets because NFS over SUNRPC is how most of them mount datasets, checkpoints and home directories, and the window opens exactly when a mount is reconnecting - the moment monitoring is most likely to be polling those sysfs files. The cost is availability only: no data disclosure, and the crash takes down the node and whatever jobs are pinned to its GPUs.

Who can reach it

Local, authenticated: a process on the host able to read the SUNRPC xprt files under sysfs, raced against RPC socket teardown. There is no remote path, and the timing dependence is reflected in the high attack-complexity rating. Containers do not see host sysfs by default.

What to do

Install a kernel carrying the fix that takes ->recv_mutex around the sysfs read; four stable branch commits are in the record. This is a kernel update and a reboot per node, schedulable as routine maintenance. In the meantime, keeping host sysfs out of reach of unprivileged workloads and not scraping the SUNRPC sysfs attributes on a tight loop both shrink the exposure.

References

https://nvd.nist.gov/vuln/detail/CVE-2022-48816 https://git.kernel.org/stable/c/9482ab4540f5bcc869b44c067ae99b5fca16bd07 https://git.kernel.org/stable/c/b49ea673e119f59c71645e2f65b3ccad857c90ee https://git.kernel.org/stable/c/fdc42287ae3f8a35cc2098307f52d7864b4bc8ed

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.