CN9K inline inbound AES-XCBC auth key overflow

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

Bug ID: 1998
Summary: CN9K inline inbound AES-XCBC auth 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 cn9k inline IPsec inbound path for AES_XCBC_MAC. I rechecked current main (8dc80afda7a52a1bd28088fe34102e7c1ba17282) on 2026-03-10 before writing this report.

The relevant inline caller path is:

```c
cn9k_eth_sec_session_create(...)
{
    ...
    rc = cnxk_on_ipsec_inb_sa_create(ipsec, crypto, inb_sa);
    ...
}
```

This inline path does not call cnxk_ipsec_xform_verify().

That matters because the exact-length check for XCBC exists in the reusable verifier:

```c
if (crypto_xform->auth.algo == RTE_CRYPTO_AUTH_AES_XCBC_MAC &&
    keylen == ROC_CPT_AES_XCBC_KEY_LENGTH)
    return 0;
```

But the inline inbound path bypasses that verifier and reaches this sink instead:

```c
case RTE_CRYPTO_AUTH_AES_XCBC_MAC:
    memcpy(in_sa->aes_xcbc.key, auth_key, auth_key_len);
    ctx_len = offsetof(struct roc_ie_on_inb_sa, aes_xcbc.selector);
    break;
```

The relevant object layout is:

```c
struct {
    uint8_t key[16];
    uint8_t unused[32];
    struct roc_ie_on_traffic_selector selector;
} aes_xcbc;
```

So the first live adjacent member starts 48 bytes after the beginning of aes_xcbc.key.

The key point here is narrow and specific:

- if the claim is only “copy into key[16] without a bound”, then any auth.key.length > 16 is already a real overwrite into adjacent in-object storage
- if the claim is specifically “corrupts the live selector member”, then the clean threshold is auth.key.length > 48

This report is about that second, narrower claim.

The same driver advertises AES_XCBC_MAC as exact-size only:

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

But the runtime inline inbound path still copies the full user-provided length into key[16].

The clean concrete case is a 64-byte AES_XCBC_MAC key:

- bytes 0..15 fill key[16]
- bytes 16..47 fill unused[32]
- bytes 48..63 overwrite the first 16 bytes of live selector

The later roc_aes_xcbc_key_derive() call does not repair that selector overwrite, because it only writes derived material into the first 48 bytes of the union region.

The local proof results for this narrow case are:

- distance_key_to_selector=48
- advertised_aes_xcbc_key_max=16
- provided_key_len=64
- returned_ctx_len=120
- overflow_bytes_into_selector=16
- selector_prefix_hex=4242424242424242
- guard_unchanged=1

Why I think this is a real bug:
- the sink is current-head shared security code
- the caller is a production inline session-create path
- the verifier that would have enforced exact XCBC length exists but is bypassed here
- the destination is a fixed in-object field, not a flexible array
- the overwritten bytes belong to a live adjacent member, selector

Suggested fix:
1. Reject AES_XCBC_MAC keys whose length is not exactly 16 before cnxk_on_ipsec_inb_sa_create() is reached on this inline path.
2. Add a local check such as if (auth_key_len != sizeof(in_sa->aes_xcbc.key)) return -EINVAL; before the memcpy().
3. Reuse the same xform verification logic for inline callers that already exists for the lookaside path.

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