CVE-2026-53094

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix stale offload->prog pointer after constant blinding

When a dev-bound-only BPF program (BPFFXDPDEVBOUNDONLY) undergoes JIT compilation with constant blinding enabled (bpfjitharden >= 2), bpfjitblindconstants() clones the program. The original prog is then freed in bpfjitprogreleaseother(), which updates aux->prog to point to the surviving clone, but fails to update offload->prog.

This leaves offload->prog pointing to the freed original program. When the network namespace is subsequently destroyed, cleanupnet() triggers bpfdevboundnetdev_unregister(), which iterates ondev->progs and calls _bpfprogoffloaddestroy(offload->prog). Accessing the freed prog causes a page fault:

BUG: unable to handle page fault for address: ffffc900085f1038 Workqueue: netns cleanup_net RIP: 0010:__bpfprogoffload_destroy+0xc/0x80 Call Trace: __bpfoffloaddevnetdevunregister+0x257/0x350 bpfdevboundnetdevunregister+0x4a/0x90 unregisternetdevicemanynotify+0x2a2/0x660 ... cleanupnet+0x21a/0x320

The test sequence that triggers this reliably is:

1. Set net.core.bpfjitharden=2 (echo 2 > /proc/sys/net/core/bpfjitharden)
2. Run xdpmetadata selftest, which creates a dev-bound-only XDP program on a veth inside a netns (./testprogs -t xdp_metadata)
3. cleanup_net -> page fault in _bpfprogoffloaddestroy

Dev-bound-only programs are unique in that they have an offload structure but go through the normal JIT path instead of bpfprogoffload_compile(). This means they are subject to constant blinding's prog clone-and-replace, while also having offload->prog that must stay in sync.

Fix this by updating offload->prog in bpfjitprogreleaseother(), alongside the existing aux->prog update. Both are back-pointers to the prog that must be kept in sync when the prog is replaced.