CN9K inline inbound IPsec HMAC SA creation out-of-bounds write

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

Bug ID: 1989
Summary: CN9K inline inbound IPsec HMAC SA creation
out-of-bounds write
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-09
Reported by: 侯朋朋 <[email protected]>

Hello DPDK Security Team,

I would like to report a potential security vulnerability in DPDK affecting the CN9K inline inbound IPsec SA creation path.

Project: DPDK
Component: drivers/common/cnxk / CN9K inbound inline IPsec Affected path: inbound SA creation path leading to cnxk_on_ipsec_inb_sa_create()
Tested current code: tested on the then-current main/master branch as of 2026-03-08
Affected versions: I have confirmed this on current head; I can provide additional version verification if useful.

The issue appears to be an out-of-bounds write caused by copying caller-provided HMAC keys into fixed-size in-struct arrays without enforcing an algorithm-appropriate upper bound in the CN9K inbound inline IPsec path.

Based on the current logic, the inbound SA creation code copies the provided authentication key into fixed internal fields for different HMAC variants. The relevant destination layout includes adjacent live members, and the copy length is based on the provided key length.

The relevant in-struct layout includes cases such as:

* sha1_or_gcm.hmac_key[48] followed by selector
* sha2.hmac_key[64] followed by hmac_iv[64] and selector

Based on this logic, if the provided key length exceeds the destination array size for the selected algorithm, the copy overwrites adjacent live fields inside the same object.

Why I believe this is a real issue:

* the inbound CN9K path copies caller-provided authentication key material into fixed-size in-struct arrays
* the first adjacent victims are live semantic fields rather than padding
* in the SHA1 HMAC case, the destination buffer is 48 bytes but a 64-byte key can be copied
* the overwrite occurs in a live inbound SA construction path

My current local proof results for the SHA1 HMAC case are:

* sha1_distance_to_selector = 48
* sha1_key_len = 64
* sha1_selector_prefix_hex = 4141414141414141

These results indicate that the bytes beyond hmac_key[48] overwrite the adjacent selector object with caller-controlled data.

At a minimum, this appears capable of causing memory corruption, crash conditions, or corrupted inbound IPsec SA state. I am not claiming code execution.

I would also like to be explicit about the current trust-boundary uncertainty:
I have confirmed the memory corruption condition locally, but I am not making a stronger claim about exploitability beyond the fact that this path copies caller-controlled key material into fixed-size in-struct buffers without a sufficiently strict upper bound.

Suggested remediation:

* enforce explicit per-algorithm upper bounds before copying authentication keys
* ensure the inbound CN9K path applies the same effective key-length constraints as the capability model and verification logic
* review similar authentication-key copy paths in related CNXK IPsec setup code

I can provide the following in follow-up if helpful:

* a minimal reproducer
* local proof notes / output
* exact tested revision details
* a proposed patch

Please credit the issue to: [email protected]
Embargo preference: no special embargo requested

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