Look up another CVE · open CVE-2026-63923 in the interactive tracker
CVE-2026-63923
octeontx2-af: validate body pcifunc in rvu_mbox_handler_rep_event_notify
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-63923 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/ethernet/marvell/octeontx2/af/rvu.c
drivers/net/ethernet/marvell/octeontx2/af/rvu.h
drivers/net/ethernet/marvell/octeontx2/af/rvu_rep.c
- What this is
- MARVELL OCTEONTX2 RVU ADMIN FUNCTION DRIVERMAINTAINERS section matched on drivers/net/ethernet/marvell/octeontx2/af/ · netdev@vger.kernel.org · Maintained
- Kernel module
- rvu_af
Check it on the machine
grep -wE 'CONFIG_ETHERNET|CONFIG_NET_VENDOR_MARVELL|CONFIG_OCTEONTX2_AF|CONFIG_OCTEONTX2_MBOX' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w rvu_afPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian does not build this code in 1 release. It does build it in 3 releases, so the answer depends on which release the machine runs.
- bookwormn
- trixieMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- n
- not enabled on any flavour - this release does not build the code
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_ETHERNET, CONFIG_NET_VENDOR_MARVELL, CONFIG_OCTEONTX2_AF, CONFIG_OCTEONTX2_MBOX
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 5.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.13 | 6.18.42 | 4467fa514482 |
| 6.13 | 7.0.12 | 68be0260e2a0 |
| 6.13 | 7.1 | 2156a29aecff |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is reached through the OcteonTX2 VF→PF→AF PCI mailbox control path, not through packet reception or any network protocol. Exploitation requires local access to an assigned SR-IOV VF device on a Marvell OCTEONTX2/CN9K/CN10K NIC.
- AC:LAttack complexity, low
- Once a VF is assigned in switchdev representor mode, the attacker fully controls the malicious `rep_event` body fields (including `pcifunc`, event flags, and MAC data) and can trigger the path deterministically via repeated mailbox messages without races or uncontrollable timing.
- PR:LPrivileges required, low
- Exploitation requires control of an assigned VF (typical cloud/tenant VM or container with SR-IOV passthrough), not host root; the PF mailbox forwarder passes every VF message ID including `MBOX_MSG_REP_EVENT_NOTIFY` to AF without an allowlist or trusted-VF gate on this path.
- UI:NUser interaction, none
- No victim user action (mounting, clicking, opening files) is required; the attacker triggers the vulnerable handler directly by sending a crafted mailbox message from their VF.
- S:CScope, changed
- In the highest-impact deployment (SR-IOV VF assigned to an untrusted VM/container tenant), corruption occurs in the host AF driver, crossing the guest/host security boundary analogous to device-mediated VM escape rather than a same-authority local privilege change.
- C:HConfidentiality impact, high
- An out-of-range body `pcifunc` makes `rvu_get_pfvf()` return a pointer past the allocated `rvu->pf[]`/`rvu->hwvf[]` arrays, and the slab-out-of-bounds write corrupts adjacent kernel heap memory in a way that can be leveraged for arbitrary kernel memory disclosure.
- I:HIntegrity impact, high
- For `RVU_EVENT_MAC_ADDR_CHANGE`, the worker performs a six-byte attacker-chosen `ether_addr_copy()` to an out-of-bounds `rvu_pfvf` target, constituting an exploitable out-of-bounds kernel heap write suitable for control-flow or privilege-escalation primitives.
- A:HAvailability impact, high
- The out-of-bounds heap write in `rvu_rep_wq_handler` can trigger a kernel oops/panic (as confirmed by KASAN slab-out-of-bounds reports) and can be repeated on demand to deny service to the host.