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(-)
diff --git a/drivers/staging/greybus/authentication.c b/drivers/staging/greybus/authentication.c index 97b9937bb..103cc15d2 100644 --- a/drivers/staging/greybus/authentication.c +++ b/drivers/staging/greybus/authentication.c @@ -109,6 +109,7 @@ static int cap_get_ims_certificate(struct gb_cap *cap, u32 class, u32 id, struct gb_cap_get_ims_certificate_request *request; struct gb_cap_get_ims_certificate_response *response; size_t max_size = gb_operation_get_payload_size_max(connection); + size_t cert_size; struct gb_operation *op; int ret;
@@ -131,9 +132,21 @@ static int cap_get_ims_certificate(struct gb_cap *cap, u32 class, u32 id, }
response = op->response->payload; + + if (op->response->payload_size < sizeof(*response)) { + ret = -EPROTO; + goto done; + } + + cert_size = op->response->payload_size - sizeof(*response); + if (cert_size > CAP_CERTIFICATE_MAX_SIZE) { + ret = -EMSGSIZE; + goto done; + } + *result = response->result_code; - *size = op->response->payload_size - sizeof(*response); - memcpy(certificate, response->certificate, *size); + *size = (u32)cert_size; + memcpy(certificate, response->certificate, cert_size);
done: gb_operation_put(op); @@ -148,6 +161,7 @@ static int cap_authenticate(struct gb_cap *cap, u32 auth_type, u8 *uid, struct gb_cap_authenticate_request *request; struct gb_cap_authenticate_response *response; size_t max_size = gb_operation_get_payload_size_max(connection); + size_t sig_size; struct gb_operation *op; int ret;
@@ -170,10 +184,22 @@ static int cap_authenticate(struct gb_cap *cap, u32 auth_type, u8 *uid, }
response = op->response->payload; + + if (op->response->payload_size < sizeof(*response)) { + ret = -EPROTO; + goto done; + } + + sig_size = op->response->payload_size - sizeof(*response); + if (sig_size > CAP_SIGNATURE_MAX_SIZE) { + ret = -EMSGSIZE; + goto done; + } + *result = response->result_code; - *signature_size = op->response->payload_size - sizeof(*response); + *signature_size = (u32)sig_size; memcpy(auth_response, response->response, sizeof(response->response)); - memcpy(signature, response->signature, *signature_size); + memcpy(signature, response->signature, sig_size);
done: gb_operation_put(op);
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
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
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 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
-
0nsec -
Greg KH -
Muhammad Bilal