Description

Calling strfmon and strfmon_l in the GNU C Library version 2.38 to 2.44 can write past the end of the caller-supplied output buffer when a conversion uses right-justified width padding. Exploitation requires an application code path that calls strfmon or strfmon_l with right-justified width padding into a destination buffer that is large enough for the padding to succeed but too small for the internal memmove call. The field width or format may be attacker-influenced or a fixed susceptible pattern in the caller. At the time of publication, no network-facing application impact is known.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-09-14T18:17:45.753Z",
  "pubdate": "2026-09-14T18:17:45.753Z",
  "executiveSummary": "A buffer overflow vulnerability exists in the GNU C Library (glibc) within the strfmon and strfmon_l functions, affecting versions 2.38 through 2.44.\nThe vulnerability occurs during the formatting of monetary values when right-justified width padding is utilized, leading to an out-of-bounds memory write past the caller-supplied output buffer.\nThis flaw represents a memory corruption vulnerability that could potentially be leveraged for arbitrary code execution or denial of service, depending on the memory layout and the surrounding application context.\nExploitation requires an attacker to influence the format strings or field widths processed by an application using these functions. While no immediate network-facing impact is known, any application processing untrusted input through strfmon or strfmon_l is potentially at risk.\nThe vulnerability is localized to the library's internal handling of monetary formatting logic, specifically failing to validate the destination buffer constraints during internal memmove operations.",
  "technicalDetails": "The root cause of the vulnerability lies in an improper bounds check within the glibc implementation of strfmon and strfmon_l. When a format specifier directs the function to perform right-justified width padding, the internal logic incorrectly calculates the required space for the final output.\nDuring the execution of the formatting routine, the library attempts to move data into the user-provided output buffer. Specifically, the internal memmove operation does not properly synchronize the expected size of the padded string with the physical capacity of the destination buffer. Because the library incorrectly assumes the buffer is sufficiently large after certain right-justification calculations, it proceeds to write data beyond the allocated boundary.\nThe attack flow requires an application to pass a format string—which may be influenced by external input—to strfmon or strfmon_l. If an attacker can control the field width parameters or the monetary format string, they can trigger a condition where the right-justified padding logic forces the internal pointer to exceed the end of the buffer.\nThis vulnerability is triggered by a specific mismatch between the width padding logic and the buffer management logic. When the field width is large enough to induce padding, the internal state machine responsible for appending characters to the buffer fails to verify the remaining space before invoking memory move operations. Consequently, the overflow occurs during the final phase of string construction.\nAs a stack or heap-based buffer overflow, the impact is highly dependent on the location of the buffer and the surrounding data structures. If the buffer is on the stack, an attacker might overwrite saved return addresses or frame pointers, potentially leading to control-flow hijacking. If the buffer resides on the heap, an attacker could potentially overwrite adjacent metadata or sensitive data structures, facilitating heap-based exploitation techniques.\nThere are no specific authentication or privilege requirements to trigger this vulnerability, as it is a library-level flaw. The primary requirement is reaching the code path where monetary formatting occurs using the affected glibc functions. The exposure is currently considered localized to the process context, though any interface exposing these formatting capabilities to user input serves as a potential attack vector."
}