https://bugs.dpdk.org/show_bug.cgi?id=1990
Bug ID: 1990
Summary: cnxk DES3 session key 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]>
Subject: [SECURITY] Potential out-of-bounds write in DPDK cnxk DES3 session key
handling
Hello DPDK Security Team,
I would like to report a potential security vulnerability in DPDK affecting the
`cnxk` crypto driver session configuration path.
Project: DPDK
Component: `drivers/crypto/cnxk` / `drivers/common/cnxk`
Affected path: DES3 session cipher setup in `fill_sess_cipher()` leading to
`roc_se_ciph_key_set()`
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 accepting oversized
DES3 keys in the `cnxk` session configuration path and then copying the full
caller-provided length into a fixed-size in-struct key buffer.
Based on the current logic, the DES3 path treats the algorithm as having a
24-byte key, but only rejects keys shorter than 24 bytes. Keys longer than 24
bytes are forwarded unchanged into the lower-level key setup routine. The sink
then copies the full provided length into the encryption key field inside the
session context.
The relevant destination layout includes adjacent live fields in this order:
* `encr_key[32]`
* `encr_iv[16]`
Based on this logic, a DES3 key longer than 32 bytes overwrites the adjacent
`encr_iv` member.
Why I believe this is a real issue:
* the DES3 path enforces only a lower bound rather than the exact expected key
length
* the oversized caller-provided key length is forwarded unchanged into the sink
* the destination is a fixed-size in-struct array
* the first adjacent victim is a live semantic field (`encr_iv`)
* the path still returns success after the adjacent overwrite
My current local proof results are:
* `distance_encr_key_to_encr_iv = 32`
* `provided_key_len = 40`
* `returned = 0`
* `overflow_bytes_into_encr_iv = 8`
* `encr_iv_prefix_hex = 4242424242424242`
These results indicate that a 40-byte DES3 key is accepted by the current path,
and the first 8 bytes beyond `encr_key[32]` overwrite the adjacent `encr_iv`
field with caller-controlled data.
At a minimum, this appears capable of causing memory corruption or corrupted
crypto session 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 accepts
oversized caller-controlled key material and copies it into a fixed-size
in-struct buffer.
Suggested remediation:
* enforce the exact DES3 key length in the session setup path rather than only
a lower bound
* add a hard upper-bound check in the lower-level key setup routine before
copying into the destination buffer
* review similar key-length validation paths in related crypto session 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.
