armv8 PMD HMAC keys overflow

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

Bug ID: 1992
Summary: armv8 PMD HMAC keys 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: pengpeng <[email protected]>

Hello DPDK maintainers,

I would like to report what appears to be a real current-head overflow in the armv8 crypto PMD HMAC setup path. I rechecked current upstream head on 2026-03-10 before writing this report.

The current-head sink appears twice, for SHA1 and SHA256 HMAC setup:

```c
rte_memcpy(sess->auth.hmac.key, xform->auth.key.data,
           xform->auth.key.length);
```

The destination layout is:

```c
struct {
    uint8_t i_key_pad[SHA_BLOCK_MAX];
    uint8_t o_key_pad[SHA_BLOCK_MAX];
    uint8_t key[SHA_BLOCK_MAX];
} hmac;
uint16_t digest_length;
```

So an oversized key first corrupts the adjacent digest_length member after key[SHA_BLOCK_MAX].

I am aware that the capability table advertises the intended HMAC key limits, but I do not think that kills the claim, because the generic create path still directly calls the PMD:

```c
ret = dev->dev_ops->sym_session_configure(dev, xforms, sess);
```

The generic core exposes capability-check helpers, but it does not automatically invoke them before the PMD copy. In other words, the current code still relies on the caller or driver to enforce the bound, and the PMD sink itself does not.

Why I think this remains a real bug:

- the sink is a literal unchecked rte_memcpy() into a fixed field
- there is no in-driver <= sizeof(sess->auth.hmac.key) guard before the copy
- the next bytes are a real adjacent member of the same session object
- the current generic create path does not automatically protect this PMD

I am intentionally making a narrow claim: this is a PMD session-configuration bug, not a statement that every application using DPDK hits it automatically.

The minimal fix is to reject HMAC key lengths larger than sizeof(sess->auth.hmac.key) before the copy.

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