# DF-5448 VERDICT — uninitialized stack returned by uvscom_cfg_read_status()
on a successful short control-IN (NO CONSUMER — latent, Info)

**Status: NOT EXECUTED (static, code-certain; Info-severity hardening class
— no SUNTAC device model exists to exercise the short-read data stage).
The defect is proven by direct source tracing below; the fix compiles clean
on the guest (fix_compile.log, combined patched build RC=0).**

## The path, line by line

1. `uvscom_cfg_read_status()` — uvscom.c:714-734:

```c
	uint8_t data[2];                                /* :719 UNINITIALIZED */
	req.bmRequestType = UT_READ_VENDOR_DEVICE;      /* :721 0xC0 = IN */
	USETW(req.wLength, 2);
	err = ucom_cfg_do_request(sc->sc_udev, &sc->sc_ucom,
	    &req, data, 0, 1000);                       /* :727-728 */
	if (err) { DPRINTFN(0, "... (ignored)\n", ...); }
	return (data[0] | (data[1] << 8));              /* :733 possibly uninit */
```

2. `ucom_cfg_do_request` — usb_serial.h:220-221 — expands to
   `usbd_do_request_proc(udev, &sc_super->sc_tq, req, ptr, flags,` **`NULL`**
   `, timo)` — the `actlen` out-parameter is hardcoded NULL.

3. `usbd_do_request_proc` — usb_request.c:780-788:

```c
	if ((len != 0) && (req->bmRequestType & UE_DIR_IN)) {
		if (err)
			memset(data, 0, len);                    /* error: zeroed */
		else if (actlen && *actlen != len)           /* actlen == NULL! */
			memset(((uint8_t *)data) + *actlen, 0, len - *actlen);
	}
```

   - request fails (STALL/timeout): buffer fully zeroed → returns 0. SAFE.
   - request **succeeds with a short data stage**: the data-phase loop
     copies only `acttemp` bytes (usb_request.c:662-665 `temp = acttemp`,
     copy at 680-681) and returns err==0; the tail-zeroization branch is
     guarded by `actlen &&` which is FALSE here (NULL) → **`data[1]` (1-byte
     reply) or both bytes (0-byte reply, a 0-length short packet terminates
     a control-IN data stage) remain uninitialized kernel stack**, which
     line 733 reads and returns.

This is exactly the uchcom class (DF-1062/DF-2342, uninitialized kernel
stack via short/malformed vendor control-IN) reached through the same core
gap as DF-5438 (ulpt status callback).

## Why Info and not Low

The **sole caller discards the return**: `uvscom_cfg_open()` uvscom.c:640
`uvscom_cfg_read_status(sc);` — value unused; `sc_lsr`/`sc_msr`/
`sc_unit_status` are fed exclusively from the interrupt pipe
(uvscom.c:425-446). The uninitialized value is computed and thrown away:
no kernel-memory disclosure, no control-flow impact today. It becomes a
live DF-1062-class leak the moment any code consumes the return value (the
NetBSD original uses this very status read to update modem-line state, so
the porting-direction risk is real). Filed as hardening; one-line fix.

## Fix

`fix.diff`: `uint8_t data[2] = {0, 0};` — compiled clean as part of the
combined patched uvscom.ko build on the guest (fix_compile.log, RC=0).
Behavioral validation not possible without a device model (fix_status=
not_testable for the runtime dimension; compile dimension validated).

## Environment

env.txt: DragonFly 6.5-DEVELOPMENT, X86_64_GENERIC, cc 8.3, guest left
pristine.

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.