From: Zhang Hewei <redacted>
Hi,
Same context as the v1 thread, replying here for the v2 series:
Discovery: manual code inspection, while auditing this driver's
handling of device-controlled responses (the MAC table walk and the
BRIDGE_ALLOC reply).
Trigger status: the unbounded-walk mechanism was reproduced in-kernel
-- a self-contained module carrying the verbatim loop shape of
mxl862xx_port_fdb_dump() (device transport stubbed) built against the
official Ubuntu 6.8.0-71 headers and run under QEMU (TCG, unmodified
official vmlinuz) never terminated on its own (100M iterations logged;
a real table holds 4-16k entries). The reproduction is automated in
Docker and needs no special hardware. I do not have access to mxl862xx
hardware, so this exercises the driver-side loop logic, not a real
device.
The BRIDGE_ALLOC validation is logic-level: the driver consumed the
firmware-supplied id with only a transport status check, so the
reserved id 0 (which doubles as the "not allocated" sentinel and the
CPU-port bridge) was accepted verbatim. Whether compliant firmware can
be made to return such values is unknown without hardware; the checks
guard against firmware that breaks the API.
The v2 diffs themselves are small and mechanical and have not been
compile-tested against a full kernel tree (no hardware here); the
reproduction module compiles and runs on the official kernel.
Thanks,
Zhang Hewei