Look up another CVE · open CVE-2026-90145 in the interactive tracker
CVE-2026-90145
hinic3: Fix skb linearization mismatch and drop skb when skb_checksum_help() failed
Published 2026-09-17 (31 days 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-90145 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.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Previously, hinic3_send_one_skb() cached the skb fragment count before calling hinic3_tx_offload(). If hinic3_tx_csum() falls back to skb_checksum_help() for unsupported tunnel packets, the skb may be linearized. Continuing to build the TX descriptor with the stale fragment count leads to a descriptor mismatch, which can trigger out-of-bounds DMA reads or IOMMU faults. Furthermore, the old code ignored the return value of skb_checksum_help(), transmitting corrupted packets with incomplete checksums upon failure. Fix this by: 1. Moving the hinic3_tx_offload() call before calculating 'num_sge' to ensure the correct fragment count is used if the SKB is linearized. 2. Propagating skb_checksum_help() errors and returning HINIC3_TX_OFFLOAD_INVALID to properly drop the skb.
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/hinic3/hinic3_tx.c
- What this is
- HUAWEI 3RD GEN ETHERNET DRIVERMAINTAINERS section matched on drivers/net/ethernet/huawei/hinic3/ · netdev@vger.kernel.org · Maintained
Check it on the machine
grep -wE 'CONFIG_ETHERNET|CONFIG_HINIC3|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.
Show whether Debian builds this, per release
Debian does not build this code in 2 releases. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixie?
- forky, sidn
- ?
- not established - no Makefile entry for the affected file
- n
- not enabled on any flavour - this release does not build the code
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switches
- CONFIG_ETHERNET, CONFIG_HINIC3, 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-17 (31 days ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.16%, higher than 5.3% 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.16 | 6.18.52 | e794cdc5c369 |
| 6.16 | 7.2.6 | 96c395977038 |
| 6.16 | 7.3 | d0c2bed6927c |
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 in hinic3_send_one_skb(), reached only from hinic3_xmit_frame (ndo_start_xmit). Stale num_sge is caused by skb_checksum_help() linearizing a locally built encapsulated skb with SKBFL_SHARED_FRAG (sendfile/splice into GRE/Geneve/IPIP); no received protocol message supplies that fragment layout.
- AC:LAttack complexity, low
- An attacker can sendfile/splice a non-GSO CHECKSUM_PARTIAL frame onto a non-VXLAN tunnel so hinic3_tx_csum() takes the unsupported-tunnel branch (l4_proto != UDP or dest != 4789) and skb_checksum_help() linearizes shared frags, desynchronizing the cached nr_frags with no race.
- PR:LPrivileges required, low
- sendfile/splice on ordinary sockets needs no capability. On a host whose egress is a Geneve/GRE/IPIP overlay over hinic3, that traffic is encapsulated in-kernel and reaches hinic3_xmit_frame as an unprivileged local user (including from a container), without init-namespace CAP_NET_ADMIN.
- UI:NUser interaction, none
- The attacker triggers hinic3_tx_csum() by transmitting their own splice'd skb; no other user must mount media, open a file, or change configuration.
- S:UScope, unchanged
- hinic3_prepare_sq_ctrl() programs a wrong BUFDESC_NUM so the NIC DMA-reads leftover SQ buf_descs in host kernel context; that is not a guest-to-host escape, and unmapped IOVAs fault rather than bypass IOMMU policy.
- C:HConfidentiality impact, high
- After skb_checksum_help() drops nr_frags, hinic3_tx_map_skb() fills only the remaining fragments while hinic3_prepare_sq_ctrl() still advertises the cached num_sge, so the NIC DMA-reads uninitialized SQ buf_descs (stale addresses/lengths) and can emit that host memory on the wire.
- I:NIntegrity impact, none
- SQ buf_descs carry only address/length for DMA_TO_DEVICE. hinic3_tx_map_skb() walks the post-linearize nr_frags and does not write out of bounds in the WQE, so there is no kernel write or control-flow primitive.
- A:HAvailability impact, high
- The same stale BUFDESC_NUM makes the device DMA from leftover or unmapped IOVAs, which the fix describes as out-of-bounds DMA reads and IOMMU faults, and can stall the send queue when hardware walks garbage descriptors.