On Thu, 12 Nov 2026 18:26:42 +0800
Junlong Wang <[email protected]> wrote:
> v2:
> - Patch 8/8: add the missing check in zxdh_bar_msg_ack_async_msg_proc(),
> the hunk described by the commit message was dropped when the v1
> changes were carried into the tree, only the reply-path check in
> zxdh_bar_chan_sync_msg_reps_get() was actually sent, so the
> VF-reachable path was unchanged (reported by maintainer review).
> - Patch 4/8: drop the paragraph claiming what the compiler does with
> the uninitialised read at -O1 and above; the fix does not depend
> on codegen for undefined behaviour, and just state that del_flag
> is read uninitialized when the group loop breaks early.
Looks good but still a couple of AI review items.
Subject: Re: [PATCH v2 0/8] net/zxdh: PF mailbox hardening
Series applies cleanly to main (26.11-rc3) and every commit builds
with -Dwerror=true. Fixes: hashes resolve and all are in released
versions, so Cc: stable is correct.
Patches 1, 2, 4, 5, 6, 7 and 8 look correct. One problem in patch 3.
[PATCH v2 3/8] net/zxdh: refuse PF mailbox requests not naming a VF
of this PF
Warning: the pfid comparison does not keep a VF on its own PF, so the
"closes the cross-PF case" claim in the commit message is wrong.
Every vport-indexed handler maps the VF vport to a table index with
zxdh_vport_to_vfid(), which for a VF is:
return v.epid * 256 + v.vfid;
pfid is not part of the index. As the commit message itself says,
vfid is allocated sequentially across all PFs of an epid. A VF can
therefore send its own, correct pcieid together with
vport = { .vf_flag = 1, .epid = <own>, .pfid = <own PF>,
.vfid = <vfid of a VF under another PF> }
zxdh_msg_head_is_own_vf() accepts it, and the handler rewrites the
port attr, MAC, VLAN and flow entries of a VF that belongs to a
different PF on the same epid.
What the check does close: requests naming a PF port (vf_flag == 0),
and requests naming any port on another epid. The residual is any VF
on the same epid, not just siblings under the same PF.
The driver has no trusted record of which vfids belong to this PF
(vfinfo[].vport is filled from the VF's own ZXDH_VF_PORT_INIT
message, so it cannot be used as the reference). Unless the PF can
obtain its vfid range from firmware, fix the commit message to
match what the code does:
A VF that forges the vport of another VF on the same epid still
cannot be told apart by the driver, since zxdh_vport_to_vfid()
does not use pfid for VF ports; protection against that case is
planned on the device side. This patch closes the PF-port and
cross-epid cases.
If firmware can report the vfid range of the PF, check
vport.vfid against that range here instead.
[PATCH v2 6/8] net/zxdh: allocate a zeroed full-size payload buffer
Info: the fix is correct only because ZXDH_BAR_MSG_PAYLOAD_MAX_LEN
equals sizeof(struct zxdh_msg_info) (both 2036, checked by compile).
Nothing enforces that. Suggest pinning it in zxdh_msg.h after the
struct definition:
static_assert(sizeof(struct zxdh_msg_info) <=
ZXDH_BAR_MSG_PAYLOAD_MAX_LEN,
"receive buffer smaller than struct zxdh_msg_info");
