[DPDK/ethdev Bug 1932] cn10k/cn20k: IPv6 header parsing bugs

[bugzilla@dpdk.org]

http://bugs.dpdk.org/show_bug.cgi?id=1932

            Bug ID: 1932
           Summary: cn10k/cn20k: IPv6 header parsing bugs
           Product: DPDK
           Version: 26.03
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: stephen@networkplumber.org
  Target Milestone: ---

The code in net/cnxk and crypto/cnxk is buggy in face of malicious IPv6
headers.
TLDR; IPV6 headers may contain bogus data (bad length) bad options and there
maybe a DoS attack with multiple extension headers.

Setting the severity of this to critical since it is the kind of bug security
researchers like to target.

Longer AI generated full report:
Title: net/cnxk: IPv6 extension header parsing lacks bounds checks and error
handling

Component: ethdev
Version: current main
Hardware: Marvell cn9k/cn10k/cn20k
Severity: normal

Description:

The IPv6 extension header walking loops in the cnxk drivers have
several related issues that can be triggered by crafted packets.
The loops use rte_ipv6_get_next_ext() which reads the extension
header length directly from packet data without any validation.

Affected files:
  - drivers/crypto/cnxk/cn9k_ipsec_la_ops.h  (ipsec_po_out_rlen_get)
  - drivers/net/cnxk/cn10k_rx.h  (nix_sec_reass_first_frag_update)
  - drivers/net/cnxk/cn20k_rx.h  (nix_sec_reass_first_frag_update)

--- Issue 1: No iteration limit ---

All three loops use "while (nh != -EINVAL)" with no cap on the
number of iterations.  A packet with a pathological chain of
syntactically valid extension headers can burn CPU cycles in the
fast path.  By comparison, rte_net_skip_ip6_ext() in lib/net caps
iterations at 5.

--- Issue 2: No bounds checking on extension length ---

rte_ipv6_get_next_ext() returns the length byte from the packet
without checking it against the mbuf data.  All three callers then
advance a raw pointer (nxt_hdr += ext_len) without verifying that
the pointer stays within the first mbuf segment.  A bogus length
byte causes out-of-bounds reads.

In cn9k this corrupts adj_len, which feeds into the output buffer
length passed to hardware.  In cn10k/cn20k this corrupts *ihl and
tot_len, which are used as rte_memcpy offsets.

--- Issue 3: Unconditional fragment header removal ---

In cn10k and cn20k, nix_sec_reass_first_frag_update() unconditionally
executes the fragment-header removal path (rte_memcpy to shift
headers forward by 8 bytes, data_off += 8, data_len -= 8) regardless
of whether the extension header walk actually found IPPROTO_FRAGMENT.

If the walk exits early (malformed packet, bounds check, iteration
limit, or simply no fragment header present), the memcpy uses a
wrong offset (tot_len may be 0 or incomplete) and the mbuf metadata
is corrupted by the unconditional 8-byte adjustment.

The function has a void return type, so callers have no way to
detect the failure.

--- Issue 4: Return type prevents error handling ---

nix_sec_reass_first_frag_update() returns void.  Even if the above
issues are fixed by breaking out of the loop, the callers
(nix_sec_reass_resolve and the inline reassembly path) cannot
distinguish success from failure and will continue processing a
corrupted mbuf.  The function should return an error indicator so
callers can drop the packet.

--- Suggested approach ---

1. Add an iteration cap (e.g., 5) to all three loops.
2. Add a bounds check (nxt_hdr + ext_len vs segment end) before
   each pointer advance.
3. Track whether IPPROTO_FRAGMENT was found; skip the memcpy and
   data_off/data_len adjustment if not.
4. Change the return type to int and update callers to handle errors.

The cn10k and cn20k loops are nearly identical and could share a
common helper, but that is a cleanup to consider separately.

Note: the correct error-handling behavior in the callers (free the
mbuf chain, set RTE_MBUF_F_RX_SEC_OFFLOAD_FAILED, bump a counter,
etc.) depends on the hardware behavior and driver conventions, and
should be decided by the maintainer with access to test hardware.

-- 
You are receiving this mail because:
You are the assignee for the bug.