There is an antipattern in umouse_request():
case UREQ(UR_GET_STATUS, UT_READ_DEVICE):
DPRINTF(("umouse: (UR_GET_STATUS, UT_READ_DEVICE)"));
if (data != NULL && len > 1) {
if (sc->hid.feature == UF_DEVICE_REMOTE_WAKEUP)
USETW(udata, UDS_REMOTE_WAKEUP);
else
USETW(udata, 0);
data->blen = len - 2;
data->bdone += 2;
}
eshort = data->blen > 0; /* XXX KEBE SAYS BOOM if data == NULL! */
break;We are seeing corner-cases where codepaths like these get reached but data == NULL. We need to be a bit more defensive here.
Many other places in umouse_request() immediately return (successfully too) if data == NULL. We should do the same in instances of this antipattern.
Dan McDonald commented on 2025-12-08T14:03:59.089-0500:
An initial test of a solution succeeded on my reproduction environment (ubuntu-22). This does not seem to affect FreeBSD from initial reports, but it does affect OmniOS per DMs.
Unsure whether or not to treat this as a security vulnerability because while root@guest can induce a SEGV using USB probes, it cannot do anything beyond send a NULL pointer it seems, so it won’t lead obviously to zone escape or anything else truly awful. It is an administrative hassle, however: such SEGV bhyve processes make a zone halt, instead of restart, requiring an explicit VM boot.
Dan McDonald commented on 2025-12-12T13:55:11.512-0500:
Upstreamed to illumos as https://www.illumos.org/issues/17784