[DPDK/cryptodev Bug 1988] CCP session cipher configuration out-of-bounds write

[bugzilla@dpdk.org]

https://bugs.dpdk.org/show_bug.cgi?id=1988

            Bug ID: 1988
           Summary: CCP session cipher configuration out-of-bounds write
           Product: DPDK
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: cryptodev
          Assignee: dev@dpdk.org
          Reporter: thomas@monjalon.net
  Target Milestone: ---
             Group: security

Report date: 2026-03-09
Reported by: 侯朋朋 <pengpeng@iscas.ac.cn>

Project: DPDK
Component: drivers/crypto/ccp
Affected path: session cipher configuration in ccp_set_session_parameters() /
ccp_configure_session_cipher()
Tested current code: tested on the then-current main/master branch as of
2026-03-08
Affected versions: I have confirmed this on current head; I can provide
additional version verification if useful

The issue appears to be an out-of-bounds write caused by copying a
user-provided cipher key into a fixed-size in-struct buffer before validating
whether the key length is supported.

In the affected path, the code stores the requested key length and copies the
key material first:

sess->cipher.key_length = cipher_xform->key.length;
rte_memcpy(sess->cipher.key, cipher_xform->key.data,
           cipher_xform->key.length);
...
if (sess->cipher.key_length == 16) ...
else if (sess->cipher.key_length == 24) ...
else if (sess->cipher.key_length == 32) ...
else {
    return -1;
}
The relevant object layout in drivers/crypto/ccp/ccp_crypto.h includes adjacent
live fields:

uint8_t key[32];
uint8_t key_ccp[32];
phys_addr_t key_phys;
uint8_t nonce[32];
Based on this logic, a key longer than 32 bytes overwrites the adjacent key_ccp
member before the function rejects the key length.

Why I believe this is a real issue:

* the key copy occurs before the supported-length validation
* the destination is a fixed-size in-struct array
* the first adjacent victim is a live semantic field (key_ccp)
* the overwrite occurs even when the function later returns -1

My current local proof results are:

distance_key_to_key_ccp = 32
requested_key_len = 40
returned = -1
overflow_bytes_into_key_ccp = 8
key_ccp_prefix_hex = 4242424242424242

These results indicate that the first 8 bytes beyond key[32] overwrite the
adjacent key_ccp field before the function reports invalid parameters.

At a minimum, this appears capable of causing memory corruption, crash
conditions, or corrupted crypto session state. I am not claiming code
execution.

I would also like to be explicit about the current trust-boundary uncertainty:
I have confirmed the memory corruption condition locally, but I am not making a
stronger claim about exploitability beyond the fact that this path copies
caller-controlled key material before validation. If you would like, I can
provide additional analysis regarding the most realistic attacker-controlled
entry conditions in deployed environments.

Suggested remediation:

* validate supported key lengths before copying into sess->cipher.key
* add a hard upper-bound check before the copy, for example rejecting lengths
greater than sizeof(sess->cipher.key)
* review similar 鈥渃opy before validate鈥� patterns in related crypto session
setup paths

Please credit the issue to: Pengpeng Hou
Embargo preference: no special embargo requested

-- 
You are receiving this mail because:
You are the assignee for the bug.