From: Michael Bommarito <michael.bommarito@gmail.com>
To: Sunil Goutham <sgoutham@marvell.com>,
Linu Cherian <lcherian@marvell.com>,
Geetha sowjanya <gakula@marvell.com>,
hariprasad <hkelam@marvell.com>,
Subbaraya Sundeep <sbhatta@marvell.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH net] octeontx2-af: validate body pcifunc in rvu_mbox_handler_rep_event_notify
Date: Wed, 20 May 2026 11:41:57 -0400 [thread overview]
Message-ID: <20260520154157.1439319-1-michael.bommarito@gmail.com> (raw)
rvu_mbox_handler_rep_event_notify() in drivers/net/ethernet/marvell/
octeontx2/af/rvu_rep.c queues a sender-controlled REP_EVENT_NOTIFY
request body verbatim, and rvu_rep_up_notify() then forwards
event->pcifunc (the nested body field, distinct from the
AF-normalised header pcifunc) into rvu_get_pfvf(), rvu_get_pf() and
the AF->PF mailbox device index without any bounds check.
A VF attached to a PF that has been put into switchdev
representor mode reaches this path: the VF mailbox handler
otx2_pfvf_mbox_handler() forwards every message id including
MBOX_MSG_REP_EVENT_NOTIFY to AF without an allowlist, and the AF
dispatcher rewrites only msg->pcifunc, leaving struct
rep_event::pcifunc attacker-controlled. The sibling
rvu_mbox_handler_esw_cfg() refuses requests whose header pcifunc
is not rvu->rep_pcifunc; this handler has no equivalent gate.
An out-of-range body pcifunc selects an &rvu->pf[]/&rvu->hwvf[]
element past the allocated array and, for RVU_EVENT_MAC_ADDR_CHANGE,
turns into a six-byte attacker-chosen OOB ether_addr_copy() target
inside the queued worker; KASAN reports a slab-out-of-bounds write
in rvu_rep_wq_handler.
Reject malformed requests at the handler entry by gating on
is_pf_func_valid(), which is already the canonical PF/VF range check
in this driver; expose it via rvu.h so callers in rvu_rep.c can use
it instead of open-coding the same range arithmetic.
Fixes: b8fea84a0468 ("octeontx2-pf: Add support to sync link state between representor and VFs")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
Reproduction
============
Tree: net mainline at v7.1-rc4 (5200f5f493f7), x86_64 QEMU,
CONFIG_KASAN_GENERIC=y, CONFIG_KUNIT=y, CONFIG_OCTEONTX2_AF=y.
Conditions: rvu_af bound to RVU AF hardware in production, or a
synthetic struct rvu in the KUnit harness used for this report.
No sysctl, capability, or namespace gate on the VF mailbox side
once switchdev/SR-IOV is provisioned.
Harness: an out-of-tree KUnit module invokes
rvu_mbox_handler_rep_event_notify() directly on a synthetic struct
rvu allocated via kunit_kzalloc with a one-PF rvu->pf[] array and
rvu->hw->total_pfs == 1. The crafted struct rep_event sets
hdr.sig = OTX2_MBOX_REQ_SIG, hdr.id = MBOX_MSG_REP_EVENT_NOTIFY,
header pcifunc 0, nested body pcifunc 2 << RVU_OTX2_PFVF_PF_SHIFT
(one PF past the synthetic array), event = RVU_EVENT_MAC_ADDR_CHANGE,
and a six-byte payload. This matches the bytes a forwarded VF
mailbox message places at the AF mbox.
Stock:
BUG: KASAN: slab-out-of-bounds in rvu_rep_wq_handler+0x100/0x280
Write of size 4 at addr ffff8880022bff03 by task kworker/0:0/9
Workqueue: rep_evt_kunit_wq rvu_rep_wq_handler
allocated by kunit_kmalloc_array+0x1b/0x50 -> make_synth_rvu
Patched: same harness, KASAN silent, the handler returns -EINVAL
at the new gate and never queues the entry; KUnit reports
"ok 1 otx2_rep_event_pcifunc_oob_demux_mac".
Regression: legitimate body pcifunc inside [0, total_pfs) is
unchanged in behaviour and continues to queue and execute on the
same code path; the gate only fires on out-of-range selectors.
Mitigations: none on the VF mailbox path. Operators who do not
provision SR-IOV VFs in switchdev representor mode are not
exposed.
The KUnit harness module is held off-list and is available on
maintainer request.
drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 2 +-
drivers/net/ethernet/marvell/octeontx2/af/rvu.h | 1 +
drivers/net/ethernet/marvell/octeontx2/af/rvu_rep.c | 8 ++++++++
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
index e40b79076358d..3cf131508ecfe 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
@@ -436,7 +436,7 @@ struct rvu_pfvf *rvu_get_pfvf(struct rvu *rvu, int pcifunc)
return &rvu->pf[rvu_get_pf(rvu->pdev, pcifunc)];
}
-static bool is_pf_func_valid(struct rvu *rvu, u16 pcifunc)
+bool is_pf_func_valid(struct rvu *rvu, u16 pcifunc)
{
int pf, vf, nvfs;
u64 cfg;
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.h b/drivers/net/ethernet/marvell/octeontx2/af/rvu.h
index a466181cf9082..de3fbd3d15d60 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.h
@@ -917,6 +917,7 @@ u16 rvu_get_rsrc_mapcount(struct rvu_pfvf *pfvf, int blkaddr);
struct rvu_pfvf *rvu_get_pfvf(struct rvu *rvu, int pcifunc);
void rvu_get_pf_numvfs(struct rvu *rvu, int pf, int *numvfs, int *hwvf);
bool is_block_implemented(struct rvu_hwinfo *hw, int blkaddr);
+bool is_pf_func_valid(struct rvu *rvu, u16 pcifunc);
bool is_pffunc_map_valid(struct rvu *rvu, u16 pcifunc, int blktype);
int rvu_get_lf(struct rvu *rvu, struct rvu_block *block, u16 pcifunc, u16 slot);
int rvu_lf_reset(struct rvu *rvu, struct rvu_block *block, int lf);
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_rep.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_rep.c
index 901f6fd40fd49..a2781e0f504e3 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_rep.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_rep.c
@@ -97,6 +97,14 @@ int rvu_mbox_handler_rep_event_notify(struct rvu *rvu, struct rep_event *req,
{
struct rep_evtq_ent *qentry;
+ /* The mailbox dispatcher normalises only the header pcifunc; the
+ * nested struct rep_event::pcifunc body field is sender-controlled
+ * and is later used by rvu_rep_up_notify() to index rvu->pf[] /
+ * rvu->hwvf[]. Reject out-of-range body selectors before queueing.
+ */
+ if (!is_pf_func_valid(rvu, req->pcifunc))
+ return -EINVAL;
+
qentry = kmalloc_obj(*qentry, GFP_ATOMIC);
if (!qentry)
return -ENOMEM;
base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
--
2.53.0
next reply other threads:[~2026-05-20 15:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 15:41 Michael Bommarito [this message]
2026-05-25 20:00 ` [PATCH net] octeontx2-af: validate body pcifunc in rvu_mbox_handler_rep_event_notify patchwork-bot+netdevbpf
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=20260520154157.1439319-1-michael.bommarito@gmail.com \
--to=michael.bommarito@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gakula@marvell.com \
--cc=hkelam@marvell.com \
--cc=kuba@kernel.org \
--cc=lcherian@marvell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sbhatta@marvell.com \
--cc=sgoutham@marvell.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox