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.
