[DPDK/cryptodev Bug 1991] CN10K inline IPsec oversized key

[bugzilla at dpdk.org]

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: dev at dpdk.org
          Reporter: thomas at monjalon.net
  Target Milestone: ---
             Group: security

Report date: 2026-03-10
Reported by: 侯朋朋 <pengpeng at iscas.ac.cn>

  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.