[DPDK/cryptodev Bug 1994] CN10K inline inbound AES-GMAC key overflow

[bugzilla@dpdk.org]

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

            Bug ID: 1994
           Summary: CN10K inline inbound AES-GMAC key 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 would like to report what appears to be a real current-head intra-object
overflow in the `cn10k` inline inbound IPsec path for `AES_GMAC`. I rechecked
current `main` (`8dc80afda7a52a1bd28088fe34102e7c1ba17282`) on 2026-03-10
before writing this report.


The relevant current-head path is:


```c
cn10k_eth_sec_session_create(...)
{
    ...
    rc = cnxk_ot_ipsec_inb_sa_fill(inb_sa_dptr, ipsec, crypto, 0);
    ...
}
```


and the update path reaches the same helper as well.


The problem is the order of operations in the shared helper. For `AES_GMAC`, it
first selects the auth key, then copies it into a fixed field, and only
afterwards validates whether the AES-family key length is one of `16/24/32`:


```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 `cn10k` path is:


```c
struct roc_ot_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 does this before the function returns `-EINVAL`:


- bytes `0..31` fill `cipher_key[32]`
- bytes `32..39` overwrite adjacent `w8`
- bytes `36..39` overwrite the live `salt[4]`


Why I think this is a real bug even though the helper later rejects the key:


- the overwrite happens first, then the error is returned
- the DPDK security-session contract expects invalid inputs to be rejected
safely
- the overwritten bytes are in a real adjacent live member, not padding or tail
allocation
- the path is a current-head production inline session-create / update path


The local proof results for the narrow `40`-byte 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`


That is enough to show controlled corruption of the adjacent `w8/salt` member
before the helper reports failure.


Suggested fix:
1. Validate `AES_GMAC` key length before the copy on the inline `cn10k` path.
2. Add a local bound such as `if (length > sizeof(cipher_key)) return -EINVAL;`
before `memcpy(cipher_key, key, length)`.
3. Reuse the same crypto-length verification logic across inline and non-inline
`cnxk` IPsec paths.

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