Regarding the bug in FreeBSD kernel driver(s)

Ian Lepore ian at freebsd.org
Tue Aug 13 20:09:03 UTC 2019


On Wed, 2019-08-14 at 01:10 +0530, Neeraj Pal wrote:
> Hi there,
> 
> After discussing the issue with the security-team, I have posted it
> publicly.
> 
> Please find the bug information given below with workaround diff:
> 
> I have observed the "NULL pointer dereference" bug inside the FreeBSD
> kernel driver code due to which kernel gets in panic (or DOS) mode
> and then
> it has to reboot.
> 
> Actually, this vulnerability resides in lots of kernel drivers like
> "uhub0", "ubt0", "umass0", "run0", "uhid0" etc.
> 
> I have tested and observed the panic for following kernel drivers:
> 
>     - usb,
>     - umass (storage),
>     - ubt(bluetooth),
>     - run0(wifi),
>     - uhid
> 
> [...]
> 
> Please confirm and let me know if any other info required.
> 

It appears the problem is limited to usb devices, not all devices in
the system.  It looks like the root of the NULL ivars problem is this
code from usb_device.c:

 if (device_probe_and_attach(iface->subdev) == 0) {
  /*
   * The USB attach arguments are only available during probe
   * and attach !
   */
  uaa->temp_dev = NULL;
  device_set_ivars(iface->subdev, NULL);
  ...

So once a device is attached the first time, its usb ivars are wiped
out.  That code was surely written in a time before the devctl stuff
was added to allow disabling/enabling a device on the fly.  I'm not
sure whether it will be easy to keep the ivar data around, but if so, I
think that would be the right fix.  

The NULL pointer checks in the patches will prevent a kernel panic, but
don't really make devctl enable work properly.  Speaking of devctl, you
don't need a program to test this, you can do it from the command line:

   devctl disable uhub2
   devctl enable uhub2
   <panic happens here>

-- Ian



More information about the freebsd-arch mailing list