summaryrefslogtreecommitdiffstats
path: root/contrib/netbsd-tests/lib/libc/stdio/t_popen.c
diff options
context:
space:
mode:
authordim <dim@FreeBSD.org>2016-12-18 14:31:11 +0000
committerdim <dim@FreeBSD.org>2016-12-18 14:31:11 +0000
commitfdc96b1347709438b325ea86883c585db249ed3a (patch)
treebfc670e3769c02c67cbb523a6d15dee9551cab6d /contrib/netbsd-tests/lib/libc/stdio/t_popen.c
parentf482b957ebe70bfe30b5c19c12f3a6d83639ef68 (diff)
downloadFreeBSD-src-fdc96b1347709438b325ea86883c585db249ed3a.zip
FreeBSD-src-fdc96b1347709438b325ea86883c585db249ed3a.tar.gz
MFC r310013 (by cperciva):
Check that blkfront devices have a non-zero number of sectors and a non-zero sector size. Such a device would be a virtual disk of zero bytes; clearly not useful, and not something we should try to attach. As a fortuitous side effect, checking that these values are non-zero here results in them not *becoming* zero later on the function. This odd behaviour began with r309124 (clang 3.9.0) but is challenging to debug; making any changes to this function whatsoever seems to affect the llvm optimizer behaviour enough to make the unexpected zeroing of the sector_size variable cease. PR: 215209 Security: The potential for variables to unexpectedly become zero has worrying consequences for security in general, but not so much in this particular context. MFC r310086: In xbd_connect(), use correct scanf conversion specifiers for the feature_barrier and feature_flush variables. Otherwise, adjacent variables on the stack, such as sector_size, may be overwritten, with disastrous results. Note that I did not see a good reason to revert the addition of zero checks introduced in r310013. Better safe than sorry. PR: 215209 Tested by: royger
Diffstat (limited to 'contrib/netbsd-tests/lib/libc/stdio/t_popen.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud