Re: [PATCH v1 0/8] net/zxdh: fix some issues reported by OSS scanner

[Stephen Hemminger <stephen@networkplumber.org>]

On Sat,  7 Nov 2026 11:04:40 +0800
Junlong Wang <wang.junlong1@zte.com.cn> wrote:

> v1:
>   This series fixes issues in the zxdh PF/VF mailbox handling that were
>   found by a code scan of the driver, reported to us by the DPDK
>   community. All of them are on the PF receive path, where fields of a
>   message written by a VF into the shared BAR window are trusted more
>   than they should be, plus two ordinary local bugs the scan found on
>   the way:
> 
> - The dispatcher hands msg_head vport/pcieid to the handlers without
>   comparing them with the sender, so a request can be aimed at any
>   port (patch 3).
> - The header module_id is checked as 8-bit but indexes a table as
>   16-bit, and the async ack msg_id indexes the 256-entry seqid table
>   without a bound check; both are out-of-bounds accesses up to a
>   function call through a wild pointer (patches 7, 8).
> - The receive buffer is allocated with the sender-declared length but
>   accessed as a full struct, corrupting the heap; and the async
>   no-ack exit leaks the buffer, allowing a guest to exhaust the PF
>   heap (patches 5, 6).
> - An uninitialised DTB entry is freed on a flow query error path,
>   and an uninitialised multicast delete flag makes the PF delete the
>   multicast entries of every port whenever one port leaves a group,
>   with no attacker involved; the latter is a v25.11 regression
>   (patches 2, 4).
> - A VLAN id above 4095 from a VF message turns into an out-of-range
>   ERAM row index (patch 1).
> 
>   The sender check of patch 3 was verified on hardware; it stops at
>   binding the request to a VF of the PF, a VF forging the identity of a
>   sibling VF of the same PF is left to device-side protection that is
>   planned. Each patch has been checked to apply on the current main
>   branch.


Overall looks good. Running AI scan locally had a couple of things
you probably should look at

Subject: Re: [PATCH v1 0/8] net/zxdh: PF mailbox hardening fixes

Applied to main (v26.11-rc2), each commit builds with -Dwerror=true.
Fixes: tags check out against history; all are in 24.11..25.11, so
Cc: stable is correct. sizeof(struct zxdh_msg_info) ==
ZXDH_BAR_MSG_PAYLOAD_MAX_LEN (2036) confirmed with a static assert,
so the premise of 6/8 holds.

One real problem: 8/8 is missing the hunk that is its main fix.


[PATCH v1 8/8] net/zxdh: check msg id before indexing the seqid table

Error: the commit message says the check is added to
zxdh_bar_msg_ack_async_msg_proc() and that the reply-path check is
only hardening, but the diff (5 insertions, one hunk) touches only
zxdh_bar_chan_sync_msg_reps_get(). After the series the VF-reachable
path is unchanged:

  static void
  zxdh_bar_msg_ack_async_msg_proc(struct zxdh_bar_msg_header *msg_header,
          uint8_t *receiver_buff)
  {
      struct zxdh_seqid_item *reps_info =
          &g_seqid_ring.reps_info_tbl[msg_header->msg_id];

zxdh_bar_irq_recv() still reaches this with a VF-written msg_id for
any async ack, and the free_id path then calls
zxdh_bar_chan_msgid_free() with the same unchecked index. Add the
check before the pointer is formed:

  static void
  zxdh_bar_msg_ack_async_msg_proc(struct zxdh_bar_msg_header *msg_header,
          uint8_t *receiver_buff)
  {
      struct zxdh_seqid_item *reps_info;

      if (msg_header->msg_id >= ZXDH_BAR_SEQID_NUM_MAX) {
          PMD_MSG_LOG(ERR, "msg_id %u is invalid", msg_header->msg_id);
          return;
      }
      reps_info = &g_seqid_ring.reps_info_tbl[msg_header->msg_id];

Looks like the hunk was dropped when the series was rebased onto 5/8,
which rewrote the caller.


[PATCH v1 4/8] net/zxdh: initialise multicast delete flag

Info: the paragraph about what the compiler does at -O1 and above is
a claim about codegen for undefined behaviour, not something the fix
depends on. Drop it and just say del_flag is read uninitialized when
the group loop breaks early, so the entry can be deleted while other
members remain.