On Fri, Sep 04, 2026 at 11:26:48AM +0530, Suraj Theekshana wrote:

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.

How well does the userspace harness actually exercise the code? Can you turn it into a valid kselftest test that we can add to the kernel tree to test the kernel code?

...

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.

Our documentation (which your LLM should have read), says that we trust hardware :)

...

Did you forget an Assisted-by: tag?

Yes. That was my mistake. I used OpenAI Codex while preparing, and validating the patch.

Please read: https://lore.kernel.org/r/2026080354-skater-urgent-31b2@gregkh

thanks,

greg k-h