[DPDK/cryptodev Bug 1992] armv8 PMD HMAC keys overflow

[DPDK/cryptodev Bug 1992] armv8 PMD HMAC keys overflow

[bugzilla]

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: dev@dpdk.org
          Reporter: thomas@monjalon.net
  Target Milestone: ---
             Group: security

Report date: 2026-03-11
Reported by: pengpeng <pengpeng@iscas.ac.cn>

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.