[PATCH v3] stdio-common: Reject insufficient character data in scanf [BZ #12701]

[Maciej W. Rozycki]

On Mon, 1 Sep 2025, Florian Weimer wrote:

> > Reject invalid formatted scanf character data with the 'c' conversion 
> > where there is not enough input available to satisfy the field width 
> > requested.  It is required by ISO C that this conversion matches a 
> > sequence of characters of exactly the number specified by the field 
> > width and it is also already documented as such in our own manual:
> >
> > "It reads precisely the next N characters, and fails if it cannot get 
> > that many."
> 
> This reportedly broke the dmstats tool in lvm2:
> 
>   glibc: sscanf parsing of %XXXc is not being returned as read
>   <https://bugzilla.redhat.com/show_bug.cgi?id=2392416>
> 
> I don't know how common it is to use %NNNc where %NNNs was meant.  It
> may not be possible to release with this change.

 Offhand I think they want to use `fread' or copy the characters by hand, 
as applicable, as `%NNNs' stops on a white-space character, which `%NNNc' 
does not; also `%NNNc' does not append a null character, though it will 
copy such ones from a stream.  I don't think `*scanf' functions provide 
the semantics seemingly required here; `%NNN[^]' is not a valid complete 
specifier.

 It's a standards compliance bug fix and my position is that we need to 
keep it even if it uncovers bugs in applications, especially given that 
with the broken `%NNNc' semantics all the corner cases cannot be correctly 
handled by the caller.

 To make people's lives easier I suppose we could choose to add a new 
version for the exported function symbols affected so that existing broken 
binaries linked against broken glibc versions keep working after a glibc 
upgrade.  That would be a limited mitigation tool only as it would break 
as soon as a broken app is linked against a fixed version of glibc, but 
perhaps good enough to buy app developers some time to fix their code.

  Maciej