[Bug 239973] Kernel Panic: device_get_ivars(9) returns NULL which leads to Null pointer dereference for multiple drivers

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239973

            Bug ID: 239973
           Summary: Kernel Panic: device_get_ivars(9) returns NULL which
                    leads to Null pointer dereference for multiple drivers
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: neerajpal09 at gmail.com
 Attachment #206706 text/plain
         mime type:

Created attachment 206706
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=206706&action=edit
kernel panic log

Kernel Panic is observed for NULL pointer dereference in FreeBSD
kernel driver code due to which kernel gets in panic then it has to reboot.

Actually, this vulnerability resides in lots of kernel drivers like
"uhub0", "ubt0", "umass0", "run0", "uhid0" etc., mostly usb devices.

Tested and observed the panic for following kernel drivers:

  - usb,
  - umass (storage),
  - ubt(bluetooth),
  - run0(wifi),
  - uhid

Devices which are using the structure
"usb_attach_arg" with device_get_ivars(9) as mentioned
below:
"struct usb_attach_arg *uaa = device_get_ivars(dev)"
are prone to NULL pointer dereference bug as there is no check
for the same and the api device_get_ivars(9) is returning NULL.

device_get_ivars(9) from the file
"/usr/src/sys/kern/subr_bus.c" returns a NULL pointer, which get assigned
to *uaa structure object (function "uhub_probe" from file
"/usr/src/sys/dev/usb/usb_bus.c"),
then, after that there is a if-else condition which is checking the
usb_mode from that structure and there panic occurs due to dereferencing
the NULL pointer
Same valid for other kernel drivers.

There are still lots of drivers which are lacking this NULL pointer
dereference check, apart from what mentioned here.

[steps to reproduce]
* devctl disable uhub0
* devctl enable uhub0 <= BOOM - panic appears

Panic occurs here, after enabling the already disabled device (but only
with usb related drivers)

[Privilege]
Root privilege is required.

[Reproducibility]
Reproducibility is 100%

[Log]
Attached file "panic.log"

[Patch]
Please find the attached patch file "patch.diff" for the file "usb_hub.c",
"ng_ubt.c",
"if_run.c", "umass.c" and "uhid.c"

After applying the patch, it first returns the "ENXIO" as mentioned in the
patch code then later invocation returns "EBUSY" as device is enabled,
which can be verified by disabling it again.

-- 
You are receiving this mail because:
You are the assignee for the bug.