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: [email protected]
Reporter: [email protected]
Target Milestone: ---
Group: security
Report date: 2026-03-09
Reported by: 侯朋朋 <[email protected]>
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.
