CN10K inline IPsec oversized key
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.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.