cap_get_ims_certificate() and cap_authenticate() derive copy lengths from response payload sizes without checking the response header size or destination capacity.
Reject responses smaller than their headers with -EMSGSIZE. Reject certificate and signature data larger than their fixed ioctl buffers with -E2BIG.
Signed-off-by: Suraj Theekshana surajtheekshana1111@gmail.com --- drivers/staging/greybus/authentication.c | 27 ++++++++++++++++++++++++ 1 file changed, 27 insertions(+)
diff --git a/drivers/staging/greybus/authentication.c b/drivers/staging/greybus/authentication.c index d8f2cd4..cbd28a3 100644 --- a/drivers/staging/greybus/authentication.c +++ b/drivers/staging/greybus/authentication.c @@ -128,9 +128,22 @@ static int cap_get_ims_certificate(struct gb_cap *cap, u32 class, u32 id, goto done; }
+ if (op->response->payload_size < sizeof(*response)) { + dev_err(cap->parent, + "invalid IMS certificate response size (%zu)\n", + op->response->payload_size); + ret = -EMSGSIZE; + goto done; + } + response = op->response->payload; *result = response->result_code; *size = op->response->payload_size - sizeof(*response); + if (*size > CAP_CERTIFICATE_MAX_SIZE) { + dev_err(cap->parent, "IMS certificate too large (%u)\n", *size); + ret = -E2BIG; + goto done; + } memcpy(certificate, response->certificate, *size);
done: @@ -167,9 +180,23 @@ static int cap_authenticate(struct gb_cap *cap, u32 auth_type, u8 *uid, goto done; }
+ if (op->response->payload_size < sizeof(*response)) { + dev_err(cap->parent, + "invalid authenticate response size (%zu)\n", + op->response->payload_size); + ret = -EMSGSIZE; + goto done; + } + response = op->response->payload; *result = response->result_code; *signature_size = op->response->payload_size - sizeof(*response); + if (*signature_size > CAP_SIGNATURE_MAX_SIZE) { + dev_err(cap->parent, "authenticate signature too large (%u)\n", + *signature_size); + ret = -E2BIG; + goto done; + } memcpy(auth_response, response->response, sizeof(response->response)); memcpy(signature, response->signature, *signature_size);
On Fri, Sep 04, 2026 at 03:46:28AM +0000, Suraj Theekshana wrote:
cap_get_ims_certificate() and cap_authenticate() derive copy lengths from response payload sizes without checking the response header size or destination capacity.
How was this found and tested?
And doesn't this info come from the hardware itself? Is it not trusted here?
Reject responses smaller than their headers with -EMSGSIZE. Reject certificate and signature data larger than their fixed ioctl buffers with -E2BIG.
Signed-off-by: Suraj Theekshana surajtheekshana1111@gmail.com
Did you forget an Assisted-by: tag?
thanks,
greg k-h
Hello Greg,
On the discovery and testing: I manually reviewed the affected code and used a userspace ASan harness based on the Greybus structures to exercise the two length calculations.
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 the change has not been tested on a physical device.
And yes, I omitted the Assisted-by tag. That was my mistake. I used OpenAI Codex while analyzing, preparing, and validating the patch.
thanks,
On Fri, Sep 4, 2026 at 10:03 AM Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Sep 04, 2026 at 03:46:28AM +0000, Suraj Theekshana wrote:
cap_get_ims_certificate() and cap_authenticate() derive copy lengths from response payload sizes without checking the response header size or destination capacity.
How was this found and tested?
And doesn't this info come from the hardware itself? Is it not trusted here?
Reject responses smaller than their headers with -EMSGSIZE. Reject certificate and signature data larger than their fixed ioctl buffers with -E2BIG.
Signed-off-by: Suraj Theekshana surajtheekshana1111@gmail.com
Did you forget an Assisted-by: tag?
thanks,
greg k-h
On Fri, Sep 04, 2026 at 10:54:49AM +0530, Suraj Theekshana wrote:
Hello Greg,
Sorry, but the mailing list rejects html emails, please fix your email client and try again? Also, please try to not top-post.
thanks,
greg k-h
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.
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.
Did you forget an Assisted-by: tag?
Yes. That was my mistake. I used OpenAI Codex while preparing, and validating the patch.
Thanks, Suraj
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
-
Greg KH -
Suraj Theekshana