UBUNTU-CVE-2026-115819: Medium severity ubuntu/eglibc vulnerability
Calling the wide scanf family of functions (swscanf, fwscanf, wscanf, vswscanf, vfwscanf and vwscanf) with a %s or %[ conversion without the 'l' length modifier in the GNU C Library version 2.2 to version 2.44 writes an extra null byte one past the end of the destination array when the converted multibyte string and its terminating null byte exactly fill that array. These conversions store each wide input character into the caller's char array as a multibyte sequence. The conversion ends with the sequence that returns to the initial shift state, which also stores the terminating null byte, and the functions then append a second null byte. A destination sized for the converted string and one terminator, as the C standard requires the caller to provide, is therefore written one byte past its end. The out-of-bounds byte is always a null byte, which may corrupt adjacent data or crash the process. An attacker who supplies the input can trigger the overflow with a string whose converted length exactly fills the destination. The narrow scanf functions, the %ls and %l[ conversions into a wchart array, and the 'a' and 'm' allocation modifiers are not affected, and storing a wide scanf conversion into a narrow char array is uncommon. This issue affects all architectures and ABIs supported by the GNU C Library.
Affected Software
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using swscanf, fwscanf, wscanf, vswscanf, vfwscanf, or vwscanf with a %s or %[ conversion without the l length modifier are exposed when the conversion writes into a caller-provided char array. The issue affects GNU C Library versions 2.2 through 2.44.
What must an attacker be able to do to trigger the overflow?
An attacker must be able to supply the input processed by the affected wide scanf conversion. Their input must convert to a multibyte string whose bytes, including its expected terminator, exactly fill the destination array.
What is the impact of a successful trigger?
The functions write one additional null byte immediately past the end of the destination array. This can corrupt adjacent data or crash the process.
Are there affected-looking scanf usages that are not vulnerable?
The narrow scanf functions are not affected. Wide scanf conversions using %ls or %l[ into a wchar_t array, as well as the a and m allocation modifiers, are not affected.
How can I identify potentially affected code before updating the library?
Audit calls to the wide scanf family for %s or %[ conversions without l that store into fixed caller-provided char arrays. Prioritize cases where untrusted input can reach those calls and where the destination can be exactly filled by converted input.