fix undefined behavior in scanf core
authorRich Felker <dalias@aerifal.cx>
Fri, 17 Apr 2020 17:46:57 +0000 (13:46 -0400)
committerRich Felker <dalias@aerifal.cx>
Fri, 17 Apr 2020 19:19:05 +0000 (15:19 -0400)
commitb287cd745c2243f8e5114331763a5a9813b5f6ee
tree860dca24a3505f530ea0a3e9161895c96b2ab468
parent19f870c3a68a959c7c6ef1de12086ac908920e5e
fix undefined behavior in scanf core

as reported/analyzed by Pascal Cuoq, the shlim and shcnt
macros/functions are called by the scanf core (vfscanf) with f->rpos
potentially null (if the FILE is not yet activated for reading at the
time of the call). in this case, they compute differences between a
null pointer (f->rpos) and a non-null one (f->buf), resulting in
undefined behavior.

it's unlikely that any observably wrong behavior occurred in practice,
at least without LTO, due to limits on what's visible to the compiler
from translation unit boundaries, but this has not been checked.

fix is simply ensuring that the FILE is activated for read mode before
entering the main scanf loop, and erroring out early if it can't be.
src/stdio/vfscanf.c