Hi Greg,
Sorry about that. I have switched Gmail to plain-text mode and am
resending with replies inline below.
How was this found and tested?
I found it while reviewing authentication.c. I then manually reviewed the affected calculations and exercised them using a userspace ASan harness based on the Greybus structures.
The harness demonstrated the 2047-byte and 1983-byte copies into the 1600-byte and 320-byte destinations, respectively. It did not exercise a live CAP ioctl or Greybus transport and did not produce an in-kernel KASAN report.
I also built drivers/staging/greybus/authentication.o with W=1 on arm64, and the submitted patch passed checkpatch without warnings. I do not have access to real Greybus hardware, so it has not been tested on a physical device.
And doesn't this info come from the hardware itself? Is it not trusted here?
Yes, the response length comes from the Greybus endpoint hardware or its firmware. My assumption was that a faulty or compromised endpoint should not be able to cause an out-of-bounds copy, especially during component authentication.
However, I did not establish that hostile Greybus hardware is within the kernel's intended threat model. If the endpoint is considered fully trusted here, then I agree that this would be defensive hardening rather than a demonstrated security-boundary issue.
Did you forget an Assisted-by: tag?
Yes. That was my mistake. I used OpenAI Codex while preparing, and validating the patch.
Thanks, Suraj