On Mon, May 11, 2026 at 03:53:00AM +0000, Greg KH wrote:
> Was this tested on any real greybus devices?

No, I do not have access to real Greybus hardware. The issue was
identified through code review of drivers/staging/greybus/authentication.c.

The vulnerable paths are:

1. payload_size is used in a subtraction without first verifying
   payload_size >= sizeof(*response), which can underflow on short
   responses.

2. The resulting size is passed directly to memcpy() into fixed-size
   UAPI buffers without validating against CAP_CERTIFICATE_MAX_SIZE
   or CAP_SIGNATURE_MAX_SIZE.

A malicious or compromised Greybus endpoint could therefore trigger
an out-of-bounds write through an oversized payload.

The fix adds the missing bounds checks before the memcpy() calls,
which matches common kernel validation patterns.

If testing on real hardware is required before merging, I am happy
to wait.

Thanks,
Muhammad Bilal

On Mon, May 11, 2026 at 3:53 AM Greg KH <gregkh@linuxfoundation.org> wrote:
On Mon, May 04, 2026 at 07:33:28PM -0400, Muhammad Bilal wrote:
> cap_get_ims_certificate() and cap_authenticate() copy variable-length
> response data directly into fixed-size UAPI buffers using the
> untrusted op->response->payload_size value without any bounds checks.
>
> A malicious or compromised Greybus endpoint can return an oversized
> certificate or signature payload, causing a kernel heap overflow.
>
> Fix both functions by:
>   - Rejecting responses shorter than sizeof(*response) with -EPROTO.
>   - Rejecting payloads exceeding CAP_CERTIFICATE_MAX_SIZE (1600) or
>     CAP_SIGNATURE_MAX_SIZE (320) with -EMSGSIZE.
>   - Copying only the validated size into the UAPI buffer.
>
> Fixes: e3eda54d0b5f ("greybus: Add Component Authentication Protocol support")
> Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
> ---
>  drivers/staging/greybus/authentication.c | 34 +++++++++++++++++++++---
>  1 file changed, 30 insertions(+), 4 deletions(-)

Was this tested on any real greybus devices?

thanks,

greg k-h