All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [DPDK/ethdev Bug 1950] Lots of problems found from review of ARK PMD
Date: Wed, 03 Jun 2026 17:24:53 +0000	[thread overview]
Message-ID: <bug-1950-3@http.bugs.dpdk.org/> (raw)

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

            Bug ID: 1950
           Summary: Lots of problems found from review of ARK PMD
           Product: DPDK
           Version: 22.03
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: stephen@networkplumber.org
  Target Milestone: ---

In addition to the problems identified by LF scan, using Claude Opus found a
lot more in this driver:

Component: drivers/net/ark
Version: main

Manual review of the full ark driver tree (ark_ethdev.c, ark_ethdev_rx.c,
ark_ethdev_tx.c, ark_pktgen.{c,h}, ark_pktchkr.{c,h}, ark_mpu.c, ark_pktdir.c)
turned up the issues below, in addition to existing scanner reports (strncat
length-arg misuse and non-NUL-terminating strncpy in process_file_args;
unchecked rte_zmalloc_socket before memcpy in ark_dev_init).

== SECURITY (suggest separate tracking item) ==

S1. Unvalidated dlopen() driver overload in check_for_ext() (ark_ethdev.c)
    Loads an arbitrary .so from the ARK_EXT_PATH environment variable
    (dlopen(path, RTLD_LOCAL | RTLD_LAZY)) and resolves ~12 rte_pmd_ark_*
    symbols that are cast to function pointers and called on the control and
    data paths. No path validation, allow-list, ownership/permission check, or
    integrity check. DPDK apps commonly run privileged, so any process able to
    influence the environment gets arbitrary in-process code execution -- a
    local code-injection / privesc vector. RTLD_LAZY defeats up-front symbol
    validation; unchecked dlsym casts are UB on ABI mismatch.
    Recommendation: gate behind a build option off by default; refuse to load
    when privileged or when the file is not root-owned / is world-writable;
    document as debug-only.

== HIGH - crashes / memory safety ==

1. NULL deref in ark_pktgen_setup() (ark_pktgen.c): pktgen toptions[] has no
   "port" entry (only pktchkr's does), but the run branch calls
   options("port")->v.INT; options() returns NULL on miss. Crashes whenever
   Pkt_gen config sets run=1.

2. ark_tx_queue_release() missing NULL guard (ark_ethdev_tx.c): ark_dev_close()
   calls it for every tx_queues[] slot and ark_dev_stop() loops over
   ark_tx_queue_stop() without checks; both deref queue->ddm / cons_index. RX
   side guards (queue == 0); TX side does not -> NULL deref on close/stop with
   any un-setup TX slot.

3. ark_dev_rx_queue_count() missing NULL guard (ark_ethdev_rx.c): dereferences
   queue with no queue == 0 check, unlike every other entry point in the file.

4. mac_addrs alloc failure not handled (ark_ethdev.c ark_dev_init, ~L381):
   failure is logged but execution falls through with mac_addrs == NULL; the
   secondary-port path (~L461) uses goto error, the primary does not.

5. error: path leaks secondary ports (ark_ethdev.c ark_dev_init, ~L480): only
   the primary mac_addrs is freed; already-probed secondary eth_devs and their
   dev_private/mac_addrs leak.

== HIGH - silent data corruption ==

6. OTLONG written through wrong union member (ark_pktgen.c pmd_set_arg,
   ark_pktchkr.c set_arg): "case OTLONG: o->v.INT = atoll(val);" truncates to
   32 bits and leaves stale upper bits in .LONG. Affects num_pkts,
   src_mac_addr, dst_mac_addr. Should be o->v.LONG.

7. src_mac_addr / num_pkts read via .v.INT in setup (both *_setup()): these are
   OTLONG; reading .INT drops upper MAC bytes (default 0xdC3cF6425060).
Adjacent
   dst_mac_addr correctly uses .LONG.

== MEDIUM ==

8. parse_ipv4_string() return type (ark_pktgen.c, ark_pktchkr.c): declared
   int32_t but builds values up to 0xFFFFFFFF via unsigned math; default
   169.254.10.240 goes negative on conversion. Should be uint32_t. "return 0"
   on parse failure also aliases a valid 0.0.0.0.

9. Divide-by-zero risk in ark_api_num_queues_per_port() (ark_mpu.c):
   num_queues / ark_ports; ark_ports derives from untrusted
   user_ext.dev_get_port_count(), unchecked for 0.

10. pkt_size_min > pkt_size_max defaults: 2006/2005 vs 1514 in both option
    tables; likely a typo.

11. dst_port / src_port default 65536: out of range for a 16-bit port.

== LOW / cleanup ==

12. Misplaced log in ark_pktchkr_wait_done(): "pktgen done" prints every loop
    iteration instead of once after completion.

13. ark_pktchkr_get_pkts_sent() returns int for a uint32_t register
    (signedness); pktgen version returns uint32_t.

14. *_parse() tokenizer/doc mismatch: comments document comma-separated args;
    toks[] omits ','.

15. inst->dev_info never set/used in ark_pkt_gen_inst / ark_pkt_chkr_inst
    (allocated via rte_malloc, not zmalloc).

16. check_for_ext() "found" is dead: never reassigned; only the -1
    dlopen-failure path is meaningful.

17. ark_mpu_configure() logs ring_size (uint32_t) with %d.

== PROCESS / TOOLING ==

P1. Non-inclusive naming not caught by review tooling: en_slaved_start
    (ark_pktgen.c toptions[] and the ark_pktgen_set_pkt_ctrl() parameter) uses
    terminology DPDK has been retiring. The substantive point is that
    checkpatches.sh / the checkpatch master|slave test should have flagged this
    and did not -- indicating the file was either grandfathered in or the check
    is not being run against this tree. Coverage gap in the tooling, not just a
    naming nit. Suggest renaming (e.g. en_gated_start) and reviewing why the
    automated check missed it.

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

                 reply	other threads:[~2026-06-03 17:24 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-1950-3@http.bugs.dpdk.org/ \
    --to=bugzilla@dpdk.org \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.