# DF-5489 — uvisor VISOR GET_CONNECTION_INFORMATION: actlen never validated;
# the USB_DEBUG connection loop consumes uninitialized kernel stack when an
# evil Visor short-transfers (Info — no production consumer)

## The code (production)

The VISOR branch of `uvisor_init()` (uvisor.c:380-428) reads an
18-byte `struct uvisor_connection_info coninfo` from the device with
`USB_SHORT_XFER_OK`:

```c
err = usbd_do_request_flags(udev, NULL,
    &req, &coninfo, USB_SHORT_XFER_OK,
    &actlen, USB_DEFAULT_TIMEOUT);          /* uvisor.c:387-389 */

if (err) {
        goto done;
}
/* NO actlen CHECK — contrast the PALM4 branch's
   "if (actlen < 12)" at uvisor.c:447-451 */
```

`usbd_do_request_flags()` is the raw entry point, not
`usbd_do_request_proc()` — the zeroize-on-error / zero-pad-on-short logic
(usb_request.c:782-787) does NOT apply, and the controller DMAs only the
bytes actually transferred. A device that answers with a zero-length or
2-byte data stage (both legal under `USB_SHORT_XFER_OK`; `err == 0`)
leaves `connections[]` / part of `num_ports` as **uninitialized stack**.

The only consumer is the `#ifdef USB_DEBUG` block (uvisor.c:395-428):
`np = UGETW(coninfo.num_ports)` (clamped to UVISOR_MAX_CONN=8 at
uvisor.c:401-403 — no OOB), then per-port
`coninfo.connections[i].port_function_id` (selects a string) and
`coninfo.connections[i].port` (printed as %d). With a USB_DEBUG kernel
and `hw.usb.uvisor.debug >= 1`, up to ~18 stale stack bytes are
disclosed to the console/msgbuf as numbers/string-selections.

**Production kernels never read `coninfo`** — dead store, no userspace
path — hence Info, same treatment as the DF-5448 (uvscom) and DF-5438
(ulpt) siblings. The bug class is real (this is exactly how DF-5455
umoscom leaked into TIOCMGET, where the buffer had a consumer), and the
PALM4 sibling branch shows the intended hygiene (`actlen < 12` check,
uvisor.c:447-451).

## Threat model

Evil/wedged Handspring VISOR-VID:PID adapter (082d:0100 etc.,
uvisor.c:254); requires a USB_DEBUG kernel build for any observable
effect.

## Evidence class

Static, code-certain — NOT executed (no Visor device model; USB_DEBUG is
not enabled on the guest's X86_64_GENERIC kernel, so the consumer does
not even compile there). Same treatment as DF-5448/DF-5438.

## Fix

`fix.diff` mirrors the PALM4 check: require
`actlen >= UVISOR_CONNECTION_INFO_SIZE` (18) before the (debug) consumer,
failing with `USB_ERR_INVAL` on a short transfer. The patched production
uvisor.ko compiles -Werror clean on the guest (fix_compile.log).