DF-2032 PoC — Kernel stack info leak via TWS_IOCTL_GET_COMPATIBILITY_INFO

Preconditions

1. Can open /dev/tws0 (default: root only, mode 0600 UID_ROOT GID_OPERATOR)
2. 3ware/LSI TWS Thunderbolt SCSI controller present

Trigger

cc -O2 -Wall -o tws_leak tws_leak.c
sudo ./tws_leak

The PoC issues TWS_IOCTL_GET_COMPATIBILITY_INFO with buffer_length >= 56 (the full struct size). The driver writes only the first 14 bytes of driver_version[32] from the version string; bytes 14..31 are raw kernel stack residue.

Expected output

driver_version[0..13]  = "10.80.00.001"
driver_version[14..31] (LEAKED stack bytes):
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
N/18 bytes non-zero -> kernel stack leaked

The leaked 18 bytes vary across invocations (stack residue: return addresses, frame pointers, etc.).

Success criterion

Non-zero bytes in driver_version[14..31] that vary across runs, confirming genuine kernel stack leak (not echoed user data — the ioctl scratch buffer is not pre-zeroed for _IOWR commands).

Fix

Add bzero(&cpkt, sizeof(cpkt)); after the declaration at line 267, or use struct tws_compatibility_packet cpkt = { {0} };.

VERDICT -- DF-2032 (Low)

Verdict: REPRODUCED (source-only)

Impact: leak:19 kernel stack residue bytes (driver_version[13..31]); HW-gated (needs tws(4)), source-confirmed

Confidence: certain

Mechanism (source-traced)

tws_ioctl_aen (tws_user.c:267) declares uninitialized stack-local struct tws_compatibility_packet cpkt. The TWS_IOCTL_GET_COMPATIBILITY_INFO handler (:304-326) populates every numeric field but only writes the leading bytes of driver_version[32] via memcpy(cpkt.driver_version, TWS_DRIVER_VERSION_STRING, sizeof(...)) at :307-308 (the string '10.80.00.001' is 13 bytes incl NUL), leaving driver_version[13..31] (19 bytes) as raw kernel-stack residue. memcpy(ubuf->data_buf, &cpkt, len) at :325 with len=sizeof(struct)=56 then copyout's the residue to userspace.

Why not runtime-reproduced

The guest (DragonFlyBSD 6.5-DEVELOPMENT #0 master DEV, KVM) has NO matching hardware: pciconf shows no mfi/tws/iir RAID controller and no amdgpu/DRM GPU; the driver therefore cannot attach and the vulnerable path is not runtime- triggerable here. The defect was confirmed at the source level by tracing the cited path:line against sys/, and the proposed fix was applied and the affected module (tws) built clean with -Werror (see fix_build.log).

Fix

tws_user.c:267: add bzero(&cpkt, sizeof(cpkt)) after the declaration (or initialize the struct) so driver_version[13..31] is not leaked as stack residue.

The standalone, git-apply-able diff is fix.diff.