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