Look up another CVE · open CVE-2026-97957 in the interactive tracker
CVE-2026-97957
net: hinic: fix mailbox segment buffer overflow
Published 2026-09-25 (24 days ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-97957 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 | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
check_mbox_seq_id_and_seg_len() validates that seq_id does not exceed SEQ_ID_MAX_VAL (42) and seg_len does not exceed MBOX_SEG_LEN (48). However, this allows the last segment (seq_id=42) to carry a full 48-byte payload, writing to offset 42*48=2016 for 48 bytes (ending at byte 2064). The receive buffer is only MBOX_MAX_BUF_SZ (2048) bytes, resulting in a 16-byte heap buffer overflow. The hinic3 driver already handles this correctly by defining MBOX_LAST_SEG_MAX_LEN and rejecting the last segment when it exceeds the remaining buffer space. Apply the same fix to the hinic driver.
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/huawei/hinic/hinic_hw_mbox.c
- What this is
- HUAWEI ETHERNET DRIVERMAINTAINERS section matched on drivers/net/ethernet/huawei/hinic/ · netdev@vger.kernel.org · Maintained
- Kernel module
- hinic
Check it on the machine
grep -wE 'CONFIG_ETHERNET|CONFIG_HINIC|CONFIG_NET_VENDOR_HUAWEI' /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 hinicPrints 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 builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le
- trixieMnot built on amd64/cloud-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/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_ETHERNET, CONFIG_HINIC, CONFIG_NET_VENDOR_HUAWEI
- 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-09-25 (24 days 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.14%, higher than 3.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- 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 |
|---|---|---|
| 5.8 | 5.10.271 | 7cc974799fde |
| 5.8 | 5.15.222 | 8de1e23bd91f |
| 5.8 | 6.1.189 | 72be1fd5d256 |
| 5.8 | 6.6.158 | c622bbc21220 |
| 5.8 | 6.12.111 | eca54a092d5f |
| 5.8 | 6.18.53 | 9f6ad383901d |
| 5.8 | 7.2.7 | 513f7b16ed0c |
| 5.8 | 7.3 | 5d4d98595743 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
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 malformed input is a mailbox header (SEQID/SEG_LEN) and 48-byte body that a VF driver writes into its own mailbox registers. The hardware delivers it to the PF's hinic_mbox_func_aeqe_handler() -> recv_mbox_handler(). The attacker is code running in a guest that owns an SR-IOV VF (or a local driver), not a remote network peer, so this is local access.
- AC:LAttack complexity, low
- The attacker sends segments seq_id 0..42 in order, each with seg_len=48. check_mbox_seq_id_and_seg_len() accepts all of them, and the memcpy at offset 42*48 overflows every time. The only setup is a VF assigned to the attacker's VM, which is the standard SR-IOV passthrough deployment. Nothing depends on timing or state outside the attacker's control.
- PR:LPrivileges required, low
- Writing raw mailbox headers needs kernel control of the VF, i.e. root inside the guest. A VM tenant always has that, and it gives no privilege on the host whose PF driver is corrupted. The random id checked by check_vf_mbox_random_id() is given to every genuine VF, so it does not stop a hostile VF driver.
- UI:NUser interaction, none
- The PF host processes the mailbox message on its own from the AEQ handler. Nobody on the host has to do anything.
- S:CScope, changed
- The bug is in a guest-controlled VF's messages, but the overflow corrupts the host kernel heap in the PF driver (recv_mbox->mbox, kzalloc(2048)). That crosses the guest-to-host boundary, like a VM escape.
- C:HConfidentiality impact, high
- Overwriting the first 16 bytes of the neighbouring kmalloc-2048 object with attacker-chosen data can corrupt pointers or length fields in that object. That is a normal route to reading arbitrary host kernel memory.
- I:HIntegrity impact, high
- recv_mbox_handler() copies 16 attacker-chosen bytes from the mailbox body past the end of the 2048-byte receive buffer. This is a controlled heap out-of-bounds write in the host kernel, which can lead to control-flow hijack.
- A:HAvailability impact, high
- The guest can repeat the corruption of the neighbouring host heap object at will, crashing or panicking the host kernel. That takes down every tenant on the host.