glibc: stack buffer overflows in the deprecated sunrpc svcunix_create and clnt_create helpers

Impact

Both deprecated sunrpc compatibility helpers copy a caller-supplied string onto the stack without a length check - svcunix_create its path argument, clnt_create its hostname argument. A program that passes an over-long, externally influenced value into either one overflows the stack, giving a crash or, where the binary was built without a stack protector, arbitrary code execution in that process. The vendor split this across two ids (CVE-2022-23218 and CVE-2022-23219) for the two functions; the component, the class of flaw, the fix release and the operator action are identical. Exposure on a GPU node depends entirely on whether anything still calls the old sunrpc API - most modern NFS and RPC tooling uses libtirpc instead - so for most fleets this is a patch-hygiene item rather than a reachable path. The NVD network-vector score reflects the worst theoretical caller, not an attack surface present by default.

Who can reach it

No direct remote surface of its own: requires a local or network-facing program on the host that still uses the deprecated glibc sunrpc helpers and feeds them an attacker-influenced path or hostname. Authentication requirements depend on that program, not on glibc.

What to do

Patch glibc to a version past 2.34 containing the sourceware fixes, or take the distribution backport (Debian LTS, Gentoo GLSA 202208-24, Oracle CPU July 2022). Because glibc is the shared library every process links against, picking up the fix means restarting every running service - in practice operators schedule a node reboot, which on a GPU node means draining jobs first. Low reachability makes this a candidate to fold into the next routine maintenance window rather than an out-of-cycle one.

Also covers 1 CVE

The vendor assigned a separate id to each affected code path. They share this advisory, this score and this fix, so they are one entry here.

References

Related entries

• Linux kernel (net/smc): When an SMC-R link is torn down, the kernel moves the QP to Error state and then destroys theCVE-2022-48673 · Linux kernel (net/smc)Critical
• Linux kernel NVMe-oF TCP host (nvme-tcp, digest error handling in io_work): The initiator kept reading from the socketCVE-2022-48686 · Linux kernel NVMe-oF TCP host (nvme-tcp, digest error handling in io_work)Critical
• Linux kernel NVMe target core (nvmet, request completion during IO connect): KASAN-confirmed use-after-free reachedCVE-2022-48697 · Linux kernel NVMe target core (nvmet, request completion during IO connect)Critical
• Linux kernel (drivers/nvme/host): On the NVMe/RDMA initiator, an async-event command can be submitted against an adminCVE-2022-48788 · Linux kernel (drivers/nvme/host)Critical
• Linux kernel (drivers/nvme/host): Same race as the RDMA variant but on NVMe/TCP, which is the far more common fabric inCVE-2022-48789 · Linux kernel (drivers/nvme/host)Critical
• Linux kernel (drivers/nvme/host): The multipath sibling list is walked without SRCU protection during path revalidationCVE-2022-49003 · Linux kernel (drivers/nvme/host)Critical