[DPDK/cryptodev Bug 1995] CN10K inline IPsec 3DES keys overflow

[bugzilla@dpdk.org]

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

            Bug ID: 1995
           Summary: CN10K inline IPsec 3DES keys overflow
           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-11
Reported by: 侯朋朋 <pengpeng@iscas.ac.cn>

Hello DPDK maintainers,


I am reporting what looks like a real current-head intra-object overflow in the
`cn10k` inline-IPsec Ethernet security path. I rechecked current `main`
(`8dc80afda7a52a1bd28088fe34102e7c1ba17282`) on 2026-03-10 before writing this
mail.


The important point is that the public DPDK security API forwards the
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 `cn10k`, the inline Ethernet path then goes straight into the SA fill
helpers:


```c
rc = cnxk_ot_ipsec_outb_sa_fill(outb_sa_dptr, ipsec, crypto, 0);
...
rc = cnxk_ot_ipsec_outb_sa_fill(outb_sa_dptr, ipsec, crypto, 0);
```


and does not first call `cnxk_ipsec_xform_verify()`.


In the shared helper, `3DES` is accepted by setting `enc_type`, but there is no
exact `== 24` runtime check before the 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 capability table for this same path advertises `3DES` as exact-size only:


```c
.key_size = {
    .min = 24,
    .max = 24,
    .increment = 0
},
```


But the runtime inline path above does not enforce that before the copy.


The destination object is:


```c
struct roc_ot_ipsec_outb_sa {
    ...
    uint8_t cipher_key[ROC_CTX_MAX_CKEY_LEN];
    union roc_ot_ipsec_outb_iv iv;
    ...
};
```


with `ROC_CTX_MAX_CKEY_LEN == 32`.


So any `3DES` key longer than `32` bytes writes through `cipher_key[32]` and
into the adjacent live `iv`.


The cleanest current-head 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 still returns `0`
- the session-create path proceeds with SA installation


This is why I think this is a strong bug:


- the caller chain is current-head and production, not test code
- the exact-size constraint is published by the driver itself
- the runtime path bypasses the verifier that would have enforced it
- the sink writes attacker-controlled data into a fixed in-object array
- the overwrite reaches a live adjacent member and the path still succeeds


I also prepared a local proof mirroring the current-head layout and write
order. The key outputs 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` length before `cnxk_ot_ipsec_*_sa_fill()` is reached on
the inline path.
2. Add a local `length <= sizeof(cipher_key)` guard inside the helper before
`memcpy()`.
3. Reuse the same xform verification logic on this inline path that already
exists elsewhere in the `cnxk` IPsec stack.

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