https://bugs.dpdk.org/show_bug.cgi?id=1996
Bug ID: 1996
Summary: CN20K inline inbound AES-GMAC key overflow
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-11
Reported by: 侯朋朋 <[email protected]>
Hello DPDK maintainers,
I would like to report what appears to be a real current-head intra-object
overflow in the `cn20k` inline inbound IPsec path for `AES_GMAC`. I rechecked
current `main` on 2026-03-10 before writing this report.
The relevant current-head path is:
```c
cn20k_eth_sec_session_create(...)
{
...
rc = cnxk_ow_ipsec_inb_sa_fill(inb_sa_dptr, ipsec, crypto, 0);
...
}
```
and the update path reaches the same helper.
The `OW` helper has the same copy-first-then-validate pattern on the `AES_GMAC`
path:
```c
case RTE_CRYPTO_AUTH_AES_GMAC:
w2->s.auth_type = ROC_IE_SA_AUTH_AES_GMAC;
key = auth_xfrm->auth.key.data;
length = auth_xfrm->auth.key.length;
...
break;
...
if (key != NULL && length != 0) {
memcpy(cipher_key, key, length);
}
...
switch (length) {
case 16:
case 24:
case 32:
break;
default:
return -EINVAL;
}
```
The destination object on this inbound `cn20k` path is:
```c
struct roc_ow_ipsec_inb_sa {
...
uint8_t cipher_key[ROC_CTX_MAX_CKEY_LEN];
union {
struct {
uint32_t rsvd8;
uint8_t salt[4];
} s;
uint64_t u64;
} w8;
...
};
```
with `ROC_CTX_MAX_CKEY_LEN == 32`.
So a `40`-byte `AES_GMAC` key overwrites the adjacent member before the
function reports invalid input:
- bytes `0..31` fill `cipher_key[32]`
- bytes `32..39` overwrite adjacent `w8`
- bytes `36..39` overwrite live `salt[4]`
Why I believe this should be accepted:
- the overwrite is in the real current-head `OW` helper used by inline inbound
session create/update
- the destination is a fixed in-object field followed by a live adjacent member
- the bug does not depend on a crash or sanitizer output
- later `-EINVAL` does not undo the earlier write
The local proof results for the narrow case are:
- `distance_cipher_key_to_w8=32`
- `distance_cipher_key_to_salt=36`
- `advertised_aes_gmac_key_max=32`
- `provided_key_len=40`
- `returned=-22`
- `overflow_bytes_into_w8=8`
- `overflow_bytes_into_salt=4`
- `w8_u64_hex=4242424242424242`
- `salt_prefix_hex=42424242`
- `guard_unchanged=1`
Suggested fix:
1. Enforce `AES_GMAC` key length before `cnxk_ow_ipsec_inb_sa_fill()` is called
on the inline path.
2. Add a direct `length <= sizeof(cipher_key)` guard before the `memcpy()`.
3. Reuse the same crypto-length verification logic across the inline and
non-inline `cnxk` IPsec implementations.
--
You are receiving this mail because:
You are the assignee for the bug.
