On Sat, 7 Nov 2026 11:04:40 +0800
Junlong Wang <[email protected]> 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.
