https://bugs.dpdk.org/show_bug.cgi?id=1997
Bug ID: 1997
Summary: CN20K inline IPsec 3DES 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 am reporting what looks like a real current-head intra-object overflow in the
`cn20k` inline-IPsec Ethernet security path. I rechecked current `main`
(`8dc80afda7a52a1bd28088fe34102e7c1ba17282`) on 2026-03-10 before writing this
mail.
As on `cn10k`, the DPDK security core forwards the caller-provided
configuration directly into the driver callback:
```c
if (instance->ops->session_create(instance->device, conf, sess)) {
rte_mempool_put(mp, (void *)sess);
return NULL;
}
```
For the `cn20k` inline path, current head then calls the `OW` SA fill helpers
directly:
```c
rc = cnxk_ow_ipsec_outb_sa_fill(outb_sa_dptr, ipsec, crypto, 0);
...
rc = cnxk_ow_ipsec_outb_sa_fill(outb_sa_dptr, ipsec, crypto, 0);
```
and again does not first call `cnxk_ipsec_xform_verify()`.
In the shared `OW` helper, `3DES` is accepted by setting `enc_type`, but there
is no exact `== 24` check before the key copy:
```c
case RTE_CRYPTO_CIPHER_3DES_CBC:
w2->s.enc_type = ROC_IE_SA_ENC_3DES_CBC;
break;
...
key = cipher_xfrm->cipher.key.data;
length = cipher_xfrm->cipher.key.length;
...
if (key != NULL && length != 0) {
memcpy(cipher_key, key, length);
...
}
```
The same `cn20k` driver publishes exact `24` for `3DES` in its capability
table:
```c
.key_size = {
.min = 24,
.max = 24,
.increment = 0
},
```
But the runtime inline path still copies the full user-provided `length` into a
fixed object field.
The destination object is:
```c
struct roc_ow_ipsec_outb_sa {
...
uint8_t cipher_key[ROC_CTX_MAX_CKEY_LEN];
union roc_ow_ipsec_outb_iv iv;
...
};
```
with `ROC_CTX_MAX_CKEY_LEN == 32`.
So any `3DES` key longer than `32` bytes writes into the adjacent live `iv`.
The cleanest concrete case is a `40`-byte `RTE_CRYPTO_CIPHER_3DES_CBC` key:
- first `32` bytes fill `cipher_key`
- next `8` bytes overwrite the beginning of `iv`
- the helper returns `0`
- `cn20k_eth_sec_session_create()` proceeds with SA installation
Why I think this should be accepted as a real bug:
- the path is current-head and reachable from the public session-create API
- capability metadata is not a runtime guard in this path
- the runtime code bypasses the verifier that would have enforced exact-length
constraints
- the sink writes through a fixed in-object array into the next live member
- the corrupted SA is still treated as successfully created
The local proof results for the narrow `40`-byte case are:
- `distance_cipher_key_to_iv=32`
- `advertised_3des_key_max=24`
- `provided_key_len=40`
- `returned=0`
- `overflow_bytes_into_iv=8`
- `iv_prefix_hex=4242424242424242`
- `guard_unchanged=1`
Suggested fix:
1. Enforce exact `3DES` key length before `cnxk_ow_ipsec_*_sa_fill()` is called
on the inline path.
2. Add a direct upper-bound guard before `memcpy(cipher_key, key, length)`.
3. Reuse the same xform-length verification logic across inline and non-inline
`cnxk` IPsec paths.
--
You are receiving this mail because:
You are the assignee for the bug.
