CVE-2026-74715: bpf: Fix netns reference imbalance in conntrack kfuncs
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix netns reference imbalance in conntrack kfuncs
The opts argument of the BPF conntrack kfuncs can point to a shared map value. bpfnfctlookup() and bpfnfctallocentry() read opts->netnsid separately when acquiring and releasing the network namespace reference.
The reference imbalance can occur as follows:
CPU 0 CPU 1 read opts->netnsid (-1) skip getnetnsbyid() write opts->netnsid (id) read opts->netnsid (id) putnet(net) / no matching get /
The reverse transition leaks the reference. Repeating the unmatched put can destroy a live namespace and crash later users.
The kernel reported:
Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] RIP: 0010:bpfprogtestrunxdp+0x52c/0x1700 Call Trace: sysbpf+0x1662/0x50c0 x64sysbpf+0x73/0xb0 dosyscall64+0xf9/0x540 entrySYSCALL64afterhwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception
Snapshot every input field of opts with READONCE() before validating or using it. The netnsid snapshot keeps the namespace get/put pair balanced, while the other snapshots keep the remaining options from changing partway through an invocation. The individual reads can still observe an inconsistent combination during a concurrent update, but each selected field value remains stable for that invocation.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to the reference imbalance?
The issue applies when BPF conntrack kfuncs use an opts argument that can point to a shared map value and its netns_id is changed concurrently. The race occurs when one CPU reads one netns_id value while another CPU updates it before the namespace reference is released.
What is the practical impact of triggering the race?
An unmatched put can destroy a network namespace that is still live, causing later users of that namespace to crash. Repeated triggering can lead to a kernel general-protection fault, KASAN null-pointer dereference, and kernel panic.
Are there indicators that this issue may already have been triggered?
Reported symptoms include a general protection fault and KASAN null-pointer dereference in bpf_prog_test_run_xdp, followed by a fatal kernel exception or panic. These symptoms indicate a crash path described for this issue, but the provided information does not establish them as unique indicators.