Look up another CVE · open CVE-2026-90146 in the interactive tracker
CVE-2026-90146
bpf, xdp: move offload check into dev_xdp_install()
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem net/core. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-90146 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixedDSA-6568-1 · 2026-10-16 · text | 6.12.113-1 | Update the kernel and reboot. DSA-6568-1 shipped the fix on 2026-10-16, in 6.12.113-1. A running kernel keeps the old code until the machine restarts. |
| 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
bpf_xdp_link_update() calls dev_xdp_install() directly and skips dev_xdp_attach(), so the checks in dev_xdp_attach() do not run. A user can make an XDP link with a normal program and then swap in an offloaded or device-bound program with BPF_LINK_UPDATE, which puts it on the software path. dev_xdp_install() is the one place all three paths go through: "ip link set xdp" and BPF_LINK_CREATE reach it via dev_xdp_attach(), and BPF_LINK_UPDATE calls it directly. So move the program checks (offloaded, bound to another device, device-bound in generic mode, native vs generic, DEVMAP and CPUMAP) there, and keep only the netlink-flag check (XDP_FLAGS_UPDATE_IF_NOEXIST) in dev_xdp_attach().
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.
net/core/dev.c
- What this is
- NETWORKING [GENERAL]MAINTAINERS section matched on net/ · netdev@vger.kernel.org · Maintained
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
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 Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/core
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.9 | 6.12.113 | 486dbe7efec2 |
| 5.9 | 6.18.52 | ea7b35dcc943 |
| 5.9 | 7.2.6 | 03022dd87407 |
| 5.9 | 7.3 | ad27ed7d2309 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DSA-6568-1 | 2026-10-16 | trixie 6.12.113-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 attacker-controlled data is the replacement program fd on bpf(BPF_LINK_UPDATE), which __sys_bpf() dispatches to link_update() then bpf_xdp_link_update() in net/core/dev.c; that local syscall installs the prog, rather than a parsed ksmbd/nfsd/packet payload.
- AC:LAttack complexity, low
- bpf_xdp_link_update() only compares prog->type and expected_attach_type, so BPF_LINK_CREATE of a normal XDP prog on a veth with XDP_FLAGS_SKB_MODE followed by BPF_LINK_UPDATE of a BPF_F_XDP_DEV_BOUND_ONLY prog that calls bpf_xdp_metadata_rx_* always bypasses the skipped dev_xdp_attach() checks, with no race.
- PR:LPrivileges required, low
- bpf_prog_load() of BPF_PROG_TYPE_XDP requires bpf_token_capable(CAP_BPF) and bpf_token_capable(CAP_NET_ADMIN) before bpf_xdp_link_attach()/link_update(); those caps, and the CAP_NET_ADMIN to add the veth attach target, are obtainable in a user/netns via unshare and BPF token delegation, not only init-namespace root.
- UI:NUser interaction, none
- The attacker loads both programs, creates the XDP link, calls BPF_LINK_UPDATE, and then drives do_xdp_generic() by sending a frame through their own veth peer; no victim mount, file open, or other cooperative action is required.
- S:UScope, unchanged
- The confused metadata kfuncs (veth_xdp_rx_hash() and friends) run in the host kernel XDP path do_xdp_generic()/bpf_prog_run_generic_xdp() and corrupt host kernel memory; this is not a KVM/Xen guest-to-host escape or an IOMMU/DMA boundary bypass.
- C:HConfidentiality impact, high
- After the skipped bpf_prog_is_dev_bound() checks, a veth-bound program can run on generic XDP's stack struct xdp_buff; veth_xdp_rx_timestamp()/veth_xdp_rx_vlan_tag() cast it to veth_xdp_buff and read skb_hwtstamps()/vlan fields through that bogus skb pointer, an unbounded kernel read into BPF maps.
- I:HIntegrity impact, high
- The same confused veth_xdp_buff.skb is passed to skb_get_hash(), which writes hash/sw_hash/l4_hash via __skb_get_hash_net(); swapping a veth-bound prog onto mlx5 native XDP likewise treats mlx5e_xdp_buff.cqe as an sk_buff and writes into the CQE, which is type confusion with a kernel write.
- A:HAvailability impact, high
- do_xdp_generic() allocates a bare struct xdp_buff, so the next RX after the bad BPF_LINK_UPDATE makes veth_xdp_rx_hash() or mlx5e_xdp_rx_timestamp() dereference adjacent stack/wrapper bytes as skb, cqe, or rq and oops; an offloaded prog swapped onto the software path also hits bpf_prog_warn_on_exec() per packet.