GPU VulnDB

Database/Kernel, userspace & hypervisor

glibc 2.37: out-of-bounds write in sprintf when formatting a padded, thousands-separated number

CVSS 9.8CVE-2023-25139Kernel, userspace & hypervisorcurated

Impact

In glibc 2.37, sprintf can write past the end of a destination buffer that was sized correctly for the output, when the format asks for a padded, thousands-separated representation of a number - the report gives 1,234,567 padded to 13 overflowing by two bytes. Any correctly written program on the host can therefore be made to corrupt adjacent memory, so the blast radius is whichever locale-aware service formats attacker-influenced numeric values. This matters on a GPU node because glibc underlies everything on it - container runtimes, the kubelet, telemetry agents, job schedulers - and the application code is not at fault, so no amount of auditing your own services removes the bug. Only glibc 2.37 is named in the report; fleets on older or newer glibc are not exposed.

Who can reach it

Local or remote, depending entirely on the calling program: an attacker needs to influence the numeric value and format width passed to sprintf by some process on the host, with a locale that uses a thousands separator. glibc itself exposes no listener.

What to do

Patch glibc past 2.37 or apply the distribution backport of the sourceware fix (bug 30068). As with any glibc update, every process linked against the library has to be restarted to pick it up, which in practice means draining the node and rebooting it. First check whether any host in the fleet actually runs 2.37 - the window of affected releases is narrow and most long-term distributions skipped it.

References

Related entries

All Kernel, userspace & hypervisor entries

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.