glibc plugs heap overflow in fopen ccs= charset handling

The GNU C Library has fixed a heap buffer overflow in how fopen parses the ccs= charset option in its mode string, tracked as CVE-2026-18374.

The flaw appears when a ccs= token is non-empty at first but becomes empty after internal stripping (for example a value that collapses to nothing once separators are removed). In that case the fallback path copied from the mode string past the comma delimiter into a heap buffer sized only for the original token, overflowing it. Specs that are empty after stripping still fail cleanly with EINVAL and no longer over-read.

Dongkyun Son of Samsung Electronics wrote the fix, bounding the fallback copy to the charset token itself. AISLE reported the issue in partnership with Red Hat. The advisory rates it CVSS 4.9: local, high attack complexity, with limited confidentiality, integrity, and availability impact. A regression test covering the overflow and the empty ccs= case was added alongside the change.

Programs that open files with attacker-influenced mode strings including ccs= were in scope; typical fixed-mode fopen callers were not.