https://bugs.dpdk.org/show_bug.cgi?id=1991
Bug ID: 1991
Summary: CN10K inline IPsec oversized key
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-10
Reported by: 侯朋朋 <[email protected]>
Dear DPDK Security Team,
I am reporting a security vulnerability discovered in the cnxk poll mode
driver, specifically affecting the CN10K inline IPsec implementation. This is
an intra-object
overflow where a lack of key length validation allows an oversized
crypto key to overwrite adjacent members in the Security Association (SA)
structure.
Vulnerability Overview
The vulnerability occurs during the creation of an inline IPsec session.
The cn10k driver fails to validate the encryption/authentication key length
against its internal
buffer size in the inline path, leading to a memory overwrite when
calling shared helper functions.
Technical Analysis
1. The Bypass (The Root Cause):
In drivers/net/cnxk/cn10k_ethdev_sec.c, the function
cn10k_eth_sec_session_create() is responsible for setting up security sessions.
Unlike the lookaside crypto path, this
inline Ethernet path does not invoke cnxk_ipsec_xform_verify(), which is
supposed to gate invalid algorithm/length combinations.
2. The Sink (The Overflow Point):
The session creation flows into the shared helper
ot_ipsec_sa_common_param_fill() located in drivers/common/cnxk/cnxk_security.c:
1 ot_ipsec_sa_common_param_fill(..., uint8_t *cipher_key, ...) {
2 ...
3 if (key != NULL && length != 0) {
4 /* Copy encryption key */
5 memcpy(cipher_key, key,
length); // OVERFLOW SINK
6 }
7 ...
8 }
Here, length is the value provided by the application via
rte_security_session_conf.crypto_xform->cipher.key.length.
3. The Object Layout:
The cipher_key pointer provided to the helper points to a fixed-size
array within struct roc_ot_ipsec_inb_sa (or outb_sa):
1 struct roc_ot_ipsec_inb_sa {
2 ...
3 uint8_t cipher_key[32]; // Fixed size
ROC_CTX_MAX_CKEY_LEN
4 union {
5 struct {
6 uint32_t rsvd8;
7 uint8_t salt[4];
8 } s;
9 uint64_t u64;
10 } w8;
// Adjacent member
11 ...
12 };
4. The Exploitation Scenario (e.g., 3DES):
If an application requests RTE_CRYPTO_CIPHER_3DES_CBC but provides a key
length of 40 bytes (which is invalid for 3DES but not rejected by the common
helper for non-AES
algorithms):
- The first 32 bytes fill cipher_key.
- The remaining 8 bytes overwrite the w8 union, which contains the
live salt value used for the IPsec transformation.
For AES-GMAC algorithms, the helper does have a switch(length) check,
but it occurs after the memcpy has already been executed, meaning the overflow
happens even if the
function eventually returns -EINVAL.
Impact
This vulnerability allows the corruption of internal SA metadata. In a
production environment where security session parameters might be influenced by
external
configurations, this can lead to:
- Cryptographic Failure: Manipulation of IVs or Salt values.
- Denial of Service: Triggering unexpected driver behavior or
crashes due to corrupted SA state.
- Information Leakage: If the IV generation logic relies on the
corrupted memory area.
Suggested Mitigation
1. Ensure cnxk_ipsec_xform_verify() is called in the
cn10k_eth_sec_session_create path before any SA filling occurs.
2. Add explicit bounds checking in ot_ipsec_sa_common_param_fill()
to ensure length never exceeds ROC_CTX_MAX_CKEY_LEN (32 bytes) before the
memcpy is executed.
--
You are receiving this mail because:
You are the assignee for the bug.
