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.

diff --git a/sys/dev/xen/blkfront/blkfront.c b/sys/dev/xen/blkfront/blkfront.c
index 4de58840341a1e98510a8ce68f3f0d40e551b73b..2e09c2eb40942fece80e90b834aacfce3e9a05c6 100644 (file)
--- a/sys/dev/xen/blkfront/blkfront.c
+++ b/sys/dev/xen/blkfront/blkfront.c
@@ -1245,6 +1245,14 @@ xbd_connect(struct xbd_softc *sc)
                    xenbus_get_otherend_path(dev));
                return;
        }
+       if ((sectors == 0) || (sector_size == 0)) {
+               xenbus_dev_fatal(dev, 0,
+                   "invalid parameters from %s:"
+                   " sectors = %lu, sector_size = %lu",
+                   xenbus_get_otherend_path(dev),
+                   sectors, sector_size);
+               return;
+       }
        err = xs_gather(XST_NIL, xenbus_get_otherend_path(dev),
             "physical-sector-size", "%lu", &phys_sector_size,
             NULL);