]> CyberLeo.Net >> Repos - FreeBSD/stable/10.git/commit
MFC r310013 (by cperciva):
authordim <dim@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Sun, 18 Dec 2016 14:31:11 +0000 (14:31 +0000)
committerdim <dim@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Sun, 18 Dec 2016 14:31:11 +0000 (14:31 +0000)
commit83f0d0da53b1516d9be55d7f60e82dfd1efd95b9
treebfc670e3769c02c67cbb523a6d15dee9551cab6d
parent23cba5f1ddb0587aef68d5e269a0ca147ff742d2
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

git-svn-id: svn://svn.freebsd.org/base/stable/10@310228 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/dev/xen/blkfront/blkfront.c