Re: [PATCH] greybus: cap: bound IMS/auth memcpy to ioctl size

[Greg KH <gregkh@linuxfoundation.org>]

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