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

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

[Suraj Theekshana]

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);
 
-- 
2.43.0

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

[Greg KH]

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

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

[Greg KH]

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

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

[Suraj Theekshana]

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

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

[Greg KH]

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