Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Aug 2019 19:50:55 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 239973] Kernel Panic: device_get_ivars(9) returns NULL which leads to Null pointer dereference for multiple drivers
Message-ID:  <bug-239973-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239973

            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@FreeBSD.org
          Reporter: neerajpal09@gmail.com
 Attachment #206706 text/plain
         mime type:

Created attachment 206706
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D206706&action=
=3Dedit
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 =3D 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 <=3D 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.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-239973-227>