CVE-2026-90146 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf, xdp: move offload check into dev_xdp_install()
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().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel contains a logic flaw within the eBPF XDP subsystem that allows for an improper bypass of security checks during program attachment updates. Specifically, the function bpf_xdp_link_update() invokes dev_xdp_install() directly to apply changes to an existing XDP link configuration. This direct invocation circumvents the execution of dev_xdp_attach(), which is responsible for performing critical validation steps before a program is attached to a network device. As a result, certain safety checks that are normally enforced when attaching programs via standard interfaces or initial creation are skipped during update operations using BPF_LINK_UPDATE.
This architectural oversight enables an attacker with the necessary privileges to manipulate XDP links in unintended ways. By initially creating an XDP link with a normal software-based program and subsequently swapping it for an offloaded, device-bound, or otherwise restricted program type via BPF_LINK_UPDATE, the system fails to validate whether the new program is compatible with the current operational mode. The vulnerability effectively allows a user to place programs that are intended for hardware acceleration or specific device bindings onto the general software processing path. This bypasses restrictions designed to prevent misconfiguration and potential instability associated with running offloaded code in a generic software context.
The technical root cause lies in the inconsistent application of validation logic across different attachment pathways. While dev_xdp_attach() correctly checks for conditions such as whether a program is offloaded, bound to another device, or incompatible with native versus generic modes, these safeguards are absent when BPF_LINK_UPDATE triggers dev_xdp_install() directly. The fix involves consolidating all relevant program validity checks into the dev_xdp_install() function, ensuring that every code path leading to installation undergoes uniform scrutiny. Only the netlink flag check for XDP_FLAGS_UPDATE_IF_NOEXIST remains in dev_xdp_attach(), as it pertains specifically to interface creation constraints rather than program compatibility validation.
From a security perspective, this vulnerability represents an authorization bypass and improper input validation failure within kernel networking components. It aligns with CWE-20 Improper Input Validation and CWE-862 Missing Authorization, as the system fails to verify that the requested operation is appropriate for the target state before execution. In terms of adversarial tactics, this flaw could be leveraged in ATT&CK technique T1059 Command and Scripting Interpreter if an attacker uses eBPF programs to execute arbitrary code or manipulate network traffic processing pipelines. The ability to force offloaded programs onto software paths can lead to system instability, performance degradation, or potential privilege escalation depending on how the misconfigured program interacts with kernel memory structures.
The operational impact of this vulnerability includes the risk of kernel panics due to incompatible execution contexts for XDP programs. Offloaded programs often rely on specific hardware interfaces and driver states that are not present when running in generic software mode. Forcing such a mismatch can cause undefined behavior, leading to denial of service conditions or exposure of sensitive kernel data through memory corruption vulnerabilities triggered by the invalid state. Furthermore, it undermines the integrity of network security policies enforced at the packet processing layer, allowing potentially malicious traffic filtering rules to be applied incorrectly.
Mitigation strategies involve applying the upstream Linux kernel patch that refactors the XDP attachment logic as described. System administrators should ensure their kernels are updated to versions where dev_xdp_install() performs comprehensive checks for offloaded status, device binding constraints, and mode compatibility regardless of the entry point used. Additionally, monitoring for unusual eBPF program attachments via audit logs can help detect attempts to exploit this flaw before it leads to system compromise. Regular security audits of kernel configurations and strict enforcement of least-privilege principles regarding BPF permissions are recommended to reduce the attack surface associated with network programming interfaces.