[DPDK/cryptodev Bug 1998] CN9K inline inbound AES-XCBC auth key overflow

[DPDK/cryptodev Bug 1998] CN9K inline inbound AES-XCBC auth key overflow

[bugzilla]

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