CVE-2026-115819: One-byte buffer overflow in wide scanf %s and %[ conversions
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.
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using GNU C Library versions 2.2 through 2.44 are exposed if they call a wide scanf-family function with %s or %[ without the l length modifier and store the result in a caller-provided char array. The issue is triggerable when attacker-controlled input can reach that conversion.
What input conditions are required to trigger the overwrite?
The converted multibyte string, including its expected terminating null byte, must exactly fill the destination array. The affected function then appends a second null byte one byte past the array boundary.
What can be done when an immediate library update is not possible?
Avoid the affected %s and %[ conversions in wide scanf-family calls where possible. The a and m allocation modifiers are not affected; %ls and %l[ conversions that store into a wchar_t array are also not affected.
Are ordinary scanf calls or all wide scanf conversions affected?
No. Narrow scanf functions are not affected, and neither are %ls or %l[ conversions into a wchar_t array. The affected cases are %s and %[ without l in swscanf, fwscanf, wscanf, vswscanf, vfwscanf, and vwscanf.