mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* greybus: CAP IMS/auth memcpy not capped to ioctl buffer
@ 2026-09-03 18:05 Suraj Theekshana
  2026-09-04  2:39 ` Willy Tarreau
  2026-09-04  3:58 ` Greg KH
  0 siblings, 2 replies; 3+ messages in thread
From: Suraj Theekshana @ 2026-09-03 18:05 UTC (permalink / raw)
  To: greybus-dev, linux-kernel; +Cc: security


[-- Attachment #1.1: Type: text/plain, Size: 3320 bytes --]

Hello,

I am reporting an unbounded memcpy in the Greybus CAP driver.

Product: Linux kernel
File:   drivers/staging/greybus/authentication.c
Header: drivers/staging/greybus/greybus_authentication.h
         include/linux/greybus/greybus_protocols.h
Tree:   torvalds/linux 8ab1afb

Observed
========

cap_get_ims_certificate() and cap_authenticate() do:

  *size = op->response->payload_size - sizeof(*response);
  memcpy(dest, src, *size);

The response buffer is allocated with gb_operation_get_payload_size_max()
and GB_OPERATION_FLAG_SHORT_RESPONSE.

The ioctl destinations are fixed:

  certificate[CAP_CERTIFICATE_MAX_SIZE]  /* 1600 */
  signature[CAP_SIGNATURE_MAX_SIZE]      /* 320  */

There is no check that payload_size >= sizeof(*response)
and no cap to 1600 / 320.

A 2048-byte payload therefore copies:

  IMS:  2048 - 1  = 2047 bytes into certificate[1600]
  AUTH: 2048 - 65 = 1983 bytes into signature[320]

A payload shorter than the response header wraps the unsigned subtract and
memcpy uses a huge length.

Expected
========

Reject payload_size < sizeof(*response) (-EMSGSIZE).
Reject copy length > CAP_CERTIFICATE_MAX_SIZE /
CAP_SIGNATURE_MAX_SIZE (-E2BIG).

Reproduce (no Greybus hardware)
===============================

  git clone --depth 1 https://github.com/torvalds/linux.git
  # tree used: 8ab1afb

  gcc -fsanitize=address -g -O0 -fno-builtin -U_FORTIFY_SOURCE \
    -I gb-poc \
    -I linux/drivers/staging/greybus \
    -I linux/include/linux/greybus \
    gb-poc/poc_cap_headers.c -o poc_cap_headers

  ./poc_cap_headers
  ./poc_cap_headers auth

ASan excerpt (IMS)
==================

CAP_CERTIFICATE_MAX_SIZE=1600 CAP_SIGNATURE_MAX_SIZE=320
[IMS] payload=2048 dest=1600 mode=ims
=================================================================
ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2047
    #0 memcpy
    #1 cap_get_ims_certificate  poc_cap_headers.c:18
    #2 main                     poc_cap_headers.c:61
Address is located in stack of thread T0
  This frame has 2 object(s):
    [48, 481) 'a'
    [560, 2173) 'ims'  <== overflows certificate[1600]
SUMMARY: AddressSanitizer: stack-buffer-overflow in memcpy
ABORTING

ASan excerpt (AUTH)
===================

CAP_CERTIFICATE_MAX_SIZE=1600 CAP_SIGNATURE_MAX_SIZE=320
[AUTH] payload=2048 dest=320
=================================================================
ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 1983
    #0 memcpy
    #1 cap_authenticate  poc_cap_headers.c:26
    #2 main              poc_cap_headers.c:54
Address is located in stack of thread T0
  This frame has 2 object(s):
    [48, 481) 'a'  <== overflows signature[320]
    [560, 2173) 'ims'
SUMMARY: AddressSanitizer: stack-buffer-overflow in memcpy
ABORTING

The PoC includes greybus_authentication.h and
greybus_protocols.h from this tree. It is not a live
CAP_IOC_* ioctl and there is no in-kernel KASAN frame.

Impact
======

Local overflow in the CAP ioctl path if a CAP connection exists and a
module answers GET_IMS_CERTIFICATE or AUTHENTICATE with an oversized or
truncated payload.
Not unauthenticated remote RCE. Same trust model as a malicious or buggy
Greybus module.

Files in the attached zip
=========================

  poc_cap_headers.c
  ktypes.h
  asan_ims.txt
  asan_auth.txt


Regards,
Suraj Theekshana

[-- Attachment #1.2: Type: text/html, Size: 3873 bytes --]

[-- Attachment #2: gb-cap-poc-8ab1afb.zip --]
[-- Type: application/zip, Size: 3771 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: greybus: CAP IMS/auth memcpy not capped to ioctl buffer
  2026-09-03 18:05 greybus: CAP IMS/auth memcpy not capped to ioctl buffer Suraj Theekshana
@ 2026-09-04  2:39 ` Willy Tarreau
  2026-09-04  3:58 ` Greg KH
  1 sibling, 0 replies; 3+ messages in thread
From: Willy Tarreau @ 2026-09-04  2:39 UTC (permalink / raw)
  To: Suraj Theekshana; +Cc: greybus-dev, linux-kernel, security

Hello,

On Thu, Sep 03, 2026 at 11:35:13PM +0530, Suraj Theekshana wrote:
> Hello,
> 
> I am reporting an unbounded memcpy in the Greybus CAP driver.

Note, there's no need to Cc security@ since you're also reporting to
public lists.

> Product: Linux kernel
> File:   drivers/staging/greybus/authentication.c
> Header: drivers/staging/greybus/greybus_authentication.h
>          include/linux/greybus/greybus_protocols.h
> Tree:   torvalds/linux 8ab1afb
> 
> Observed
> ========
> 
> cap_get_ims_certificate() and cap_authenticate() do:
> 
>   *size = op->response->payload_size - sizeof(*response);
>   memcpy(dest, src, *size);
> 
> The response buffer is allocated with gb_operation_get_payload_size_max()
> and GB_OPERATION_FLAG_SHORT_RESPONSE.
> 
> The ioctl destinations are fixed:
> 
>   certificate[CAP_CERTIFICATE_MAX_SIZE]  /* 1600 */
>   signature[CAP_SIGNATURE_MAX_SIZE]      /* 320  */
> 
> There is no check that payload_size >= sizeof(*response)
> and no cap to 1600 / 320.
> 
> A 2048-byte payload therefore copies:
> 
>   IMS:  2048 - 1  = 2047 bytes into certificate[1600]
>   AUTH: 2048 - 65 = 1983 bytes into signature[320]
> 
> A payload shorter than the response header wraps the unsigned subtract and
> memcpy uses a huge length.
> 
> Expected
> ========
> 
> Reject payload_size < sizeof(*response) (-EMSGSIZE).
> Reject copy length > CAP_CERTIFICATE_MAX_SIZE /
> CAP_SIGNATURE_MAX_SIZE (-E2BIG).
> 
> Reproduce (no Greybus hardware)
> ===============================
> 
>   git clone --depth 1 https://github.com/torvalds/linux.git
>   # tree used: 8ab1afb
> 
>   gcc -fsanitize=address -g -O0 -fno-builtin -U_FORTIFY_SOURCE \
>     -I gb-poc \
>     -I linux/drivers/staging/greybus \
>     -I linux/include/linux/greybus \
>     gb-poc/poc_cap_headers.c -o poc_cap_headers
> 
>   ./poc_cap_headers
>   ./poc_cap_headers auth
> 
> ASan excerpt (IMS)
> ==================
> 
> CAP_CERTIFICATE_MAX_SIZE=1600 CAP_SIGNATURE_MAX_SIZE=320
> [IMS] payload=2048 dest=1600 mode=ims
> =================================================================
> ERROR: AddressSanitizer: stack-buffer-overflow
> WRITE of size 2047
>     #0 memcpy
>     #1 cap_get_ims_certificate  poc_cap_headers.c:18
>     #2 main                     poc_cap_headers.c:61
> Address is located in stack of thread T0
>   This frame has 2 object(s):
>     [48, 481) 'a'
>     [560, 2173) 'ims'  <== overflows certificate[1600]
> SUMMARY: AddressSanitizer: stack-buffer-overflow in memcpy
> ABORTING
> 
> ASan excerpt (AUTH)
> ===================
> 
> CAP_CERTIFICATE_MAX_SIZE=1600 CAP_SIGNATURE_MAX_SIZE=320
> [AUTH] payload=2048 dest=320
> =================================================================
> ERROR: AddressSanitizer: stack-buffer-overflow
> WRITE of size 1983
>     #0 memcpy
>     #1 cap_authenticate  poc_cap_headers.c:26
>     #2 main              poc_cap_headers.c:54
> Address is located in stack of thread T0
>   This frame has 2 object(s):
>     [48, 481) 'a'  <== overflows signature[320]
>     [560, 2173) 'ims'
> SUMMARY: AddressSanitizer: stack-buffer-overflow in memcpy
> ABORTING
> 
> The PoC includes greybus_authentication.h and
> greybus_protocols.h from this tree. It is not a live
> CAP_IOC_* ioctl and there is no in-kernel KASAN frame.
> 
> Impact
> ======
> 
> Local overflow in the CAP ioctl path if a CAP connection exists and a
> module answers GET_IMS_CERTIFICATE or AUTHENTICATE with an oversized or
> truncated payload.
> Not unauthenticated remote RCE. Same trust model as a malicious or buggy
> Greybus module.
> 
> Files in the attached zip
> =========================

Please avoid sending binary files, as developers are unlikely to open
them.

>   poc_cap_headers.c
>   ktypes.h
>   asan_ims.txt
>   asan_auth.txt

As requested in the doc where you found the security list's email,
please always try to propose a working patch so you can get full
credit for finding and fixing issues and you can save maintainers'
time. Please also see Docuemntation/process/submitting-patches.rst.

> Regards,
> Suraj Theekshana

Thanks,
Willy

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: greybus: CAP IMS/auth memcpy not capped to ioctl buffer
  2026-09-03 18:05 greybus: CAP IMS/auth memcpy not capped to ioctl buffer Suraj Theekshana
  2026-09-04  2:39 ` Willy Tarreau
@ 2026-09-04  3:58 ` Greg KH
  1 sibling, 0 replies; 3+ messages in thread
From: Greg KH @ 2026-09-04  3:58 UTC (permalink / raw)
  To: Suraj Theekshana; +Cc: greybus-dev, linux-kernel, security

On Thu, Sep 03, 2026 at 11:35:13PM +0530, Suraj Theekshana wrote:
> Reproduce (no Greybus hardware)
> ===============================
> 
>   git clone --depth 1 https://github.com/torvalds/linux.git
>   # tree used: 8ab1afb
> 
>   gcc -fsanitize=address -g -O0 -fno-builtin -U_FORTIFY_SOURCE \
>     -I gb-poc \
>     -I linux/drivers/staging/greybus \
>     -I linux/include/linux/greybus \
>     gb-poc/poc_cap_headers.c -o poc_cap_headers
> 
>   ./poc_cap_headers
>   ./poc_cap_headers auth

That's not a reproducer if you don't have the hardware, right?

> Files in the attached zip
> =========================

As Willy said, please just provide a patch, like the documentation asked
for, that you have tested with your reproducer.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-09-04  4:31 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-03 18:05 greybus: CAP IMS/auth memcpy not capped to ioctl buffer Suraj Theekshana
2026-09-04  2:39 ` Willy Tarreau
2026-09-04  3:58 ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®