CVE-2026-45932

What it actually does

This is a local authorization bypass in the Linux kernel's eBPF handling for tcx and netkit devices. A low-privileged local user could invoke BPF_PROG_DETACH without supplying a program file descriptor and bypass the intended capability checks. As a result, the user may detach BPF programs from tcx or netkit hooks even when they do not have CAP_NET_ADMIN or CAP_SYS_ADMIN. Depending on how the host uses BPF, this can disable traffic control, packet filtering, observability, policy enforcement, or other kernel-level networking logic, causing integrity and availability impact and limited confidentiality impact.

Why it matters to the business

An attacker who already has a local account or code execution on a Linux system may be able to disable security, monitoring, or network-control programs implemented with eBPF. This can reduce visibility, weaken network policy enforcement, disrupt workloads, or help an intruder hide follow-on activity. The issue is not known to be exploited in the wild and has a low EPSS score, but affected systems that rely on tcx or netkit BPF hooks should be prioritized because the attack is low-complexity once local access exists.

How an attack unfolds

An attacker first obtains low-privileged local access to an affected Linux system, such as through a shell, compromised service account, container escape chain, or malicious local workload. The attacker then identifies tcx or netkit devices with attached BPF programs. Instead of using a normal detach operation that supplies a program file descriptor and triggers permission checks, the attacker invokes the BPF_PROG_DETACH command without a program fd. On vulnerable kernels, the missing program fd path fails to enforce the required CAP_NET_ADMIN or CAP_SYS_ADMIN check, allowing the detach to proceed. The attacker can then remove BPF programs that enforce traffic control, inspection, filtering, telemetry, or policy, potentially disrupting operations or weakening defenses before conducting additional activity.

How to fix it

Upgrade the Linux kernel to a vendor-supported build that includes the upstream fix for the tcx/netkit BPF_PROG_DETACH permission check. If distribution-specific fixed package versions are not yet published, track the relevant security advisories from the operating system vendor and deploy the first kernel update that references this flaw or the BPF tcx/netkit detach permission fix. Reboot systems after kernel updates, or use a vendor-supported live patch if available and explicitly confirmed to contain the fix. As mitigations until patching is complete, restrict local shell access, reduce untrusted local workloads, limit container privileges, avoid granting broad BPF-related capabilities, restrict unprivileged BPF where supported, and monitor for unexpected changes to tcx/netkit BPF attachments.

How to confirm the fix worked

Confirm exposure by checking the running kernel version against the fixed kernel version provided by the Linux distribution or kernel vendor. Validate that systems have rebooted into the patched kernel, not merely installed the package. Where feasible in a controlled test environment, attempt a BPF_PROG_DETACH operation against a tcx or netkit attachment from a user lacking CAP_NET_ADMIN and CAP_SYS_ADMIN; the patched behavior should deny the operation. Also verify that expected BPF programs remain attached to tcx/netkit hooks after patching and that security or observability agents relying on BPF report healthy status.

Typical attack path

1. Gain low-privileged local execution on an affected Linux host.
2. Enumerate networking devices and BPF attachments, especially tcx or netkit hooks.
3. Invoke the bpf() system call with BPF_PROG_DETACH against a tcx or netkit attachment without providing a program file descriptor.
4. Bypass the missing capability check and detach the target BPF program.
5. Use the removed BPF hook to disrupt service, bypass local network policy, reduce monitoring, or conceal subsequent actions.

How to detect it

Review host audit logs, eBPF management telemetry, endpoint detection logs, and network/security agent logs for unexpected BPF detach activity involving tcx or netkit. Useful sources include Linux auditd records for the bpf() syscall, EDR telemetry that captures syscalls or capability use, logs from BPF-based security tools, traffic-control management logs, and configuration management records showing changes to BPF attachments. Investigate detach events initiated by non-administrative users, processes running without CAP_NET_ADMIN or CAP_SYS_ADMIN, containerized workloads, build jobs, scripting runtimes, or unusual binaries. Compare current BPF attachment state to a known-good baseline; unexpected removal of tcx or netkit programs may indicate exploitation or attempted exploitation. Also look for secondary signs such as sudden loss of BPF-based telemetry, policy bypass alerts, service disruption, or gaps in network enforcement immediately after local process activity.

• BPF_PROG_DETACH
• tcx
• netkit
• bpf(BPF_PROG_DETACH
• syscall=bpf
• comm="bpftool"
• bpftool net detach
• bpftool prog detach
• operation="BPF_PROG_DETACH"
• cmd=BPF_PROG_DETACH
• CAP_NET_ADMIN
• CAP_SYS_ADMIN

What your security team should do

• Inventory Linux systems that use eBPF for networking, traffic control, policy enforcement, runtime security, or observability, with special attention to tcx and netkit usage.
• Prioritize patching hosts that run untrusted local workloads, multi-user workloads, containers, CI/CD jobs, shared compute, or internet-facing services that could provide an initial foothold.
• Deploy the vendor-fixed kernel and ensure each system is rebooted into the corrected kernel version.
• Restrict local user access and remove unnecessary privileges such as CAP_NET_ADMIN, CAP_SYS_ADMIN, CAP_BPF, or broad container privileges from workloads that do not require them.
• Enable or review audit/eBPF telemetry capable of recording bpf() detach operations and changes to tcx/netkit attachments.
• After remediation, verify that critical BPF-based security, network policy, and monitoring programs are still attached and functioning.
• Because there is no known exploitation and EPSS is low, treat this as important for high-risk Linux fleets rather than an emergency internet-wide exposure.