cnxk DES3 session key out-of-bounds write

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.