CN10K inline inbound AES-GMAC key overflow

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: [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 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.