Bug 246964
| Summary: | bhyve usb_mouse SIGSEGV on null pointer dereference | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Ali Abdallah <ali.abdallah> | ||||||||||
| Component: | bhyve | Assignee: | freebsd-virtualization (Nobody) <virtualization> | ||||||||||
| Status: | Closed FIXED | ||||||||||||
| Severity: | Affects Some People | CC: | grehan | ||||||||||
| Priority: | --- | ||||||||||||
| Version: | 12.1-RELEASE | ||||||||||||
| Hardware: | amd64 | ||||||||||||
| OS: | Any | ||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 215207 [details]
Fix null pointer dereference in usb_mouse
Actually there is also another null pointer dereference. Patch updated.
Thanks for the report. I was able to reproduce this so should be able to get your fix in. Created attachment 215213 [details]
Fix null pointer dereferences in usb_mouse
Fix a couple of more dereferences in usb_mouse.
Please note that running 'scan-build80 make' in /usr/src/usr.sbin/bhyve reveals also other dereference of null pointers (no more in usb_mouse). I think those also can be potentially triggered in some way and should be fixed.
Sure, I'll give that a run. Created attachment 215214 [details]
lsusb -v log
The command in supportconfig that resulted in the crash was "lsusb -vv", though an "lsusb -v" will also result in the core. Log attached from running that on an Ubuntu 20.04 live ISO. The root cause of this issue was a bug in the XHCI TRB processing loop, which resulted in the back-end control transfer routine being called twice. While this was mostly benign, the GET_STATUS handler did not recognize this case and assumed a valid data pointer. I have a patch for this that I'll put up for review. The NULL derefs will be fixed in a follow-up commit. A commit references this bug: Author: grehan Date: Fri Jun 26 08:20:39 UTC 2020 New revision: 362644 URL: https://svnweb.freebsd.org/changeset/base/362644 Log: Prevent calling USB backends multiple times. The TRB processing loop could potentially call a back-end twice with the same status transaction. While this was generally benign, some code paths in the tablet backend weren't set up to handle this case, resulting in a NULL dereference. Fix by - returning a STALL error when an invalid request was seen in the backend - skipping a call to the backend if the number of packets in a status transaction was zero (this code fragment was taken from the Intel ACRN xhci backend) PR: 246964 Reported by: Ali Abdallah Discussed with: Leon Dang (author) Reviewed by: jhb (#bhyve), Leon Dang Approved by: jhb Obtained from: Intel ACRN (partially) MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D25228 Changes: head/usr.sbin/bhyve/pci_xhci.c head/usr.sbin/bhyve/usb_mouse.c |
Created attachment 215206 [details] Fix null pointer dereference in usb_mouse By chance when I was running 'supportconfig' on a openSUSE 15.1 guest under bhyve, it crashes with SIGSEGV. Debugging and checking the code revealed the problem. usb_mouse.c:538 eshort = data->blen > 0; the data pointer above is accessed while being null. Attached is a trivial patch that fixes the issue for me.