CVE-2026-53094

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix stale offload-&gt;prog pointer after constant blinding<br /> <br /> When a dev-bound-only BPF program (BPF_F_XDP_DEV_BOUND_ONLY) undergoes<br /> JIT compilation with constant blinding enabled (bpf_jit_harden &gt;= 2),<br /> bpf_jit_blind_constants() clones the program. The original prog is then<br /> freed in bpf_jit_prog_release_other(), which updates aux-&gt;prog to point<br /> to the surviving clone, but fails to update offload-&gt;prog.<br /> <br /> This leaves offload-&gt;prog pointing to the freed original program. When<br /> the network namespace is subsequently destroyed, cleanup_net() triggers<br /> bpf_dev_bound_netdev_unregister(), which iterates ondev-&gt;progs and calls<br /> __bpf_prog_offload_destroy(offload-&gt;prog). Accessing the freed prog<br /> causes a page fault:<br /> <br /> BUG: unable to handle page fault for address: ffffc900085f1038<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:__bpf_prog_offload_destroy+0xc/0x80<br /> Call Trace:<br /> __bpf_offload_dev_netdev_unregister+0x257/0x350<br /> bpf_dev_bound_netdev_unregister+0x4a/0x90<br /> unregister_netdevice_many_notify+0x2a2/0x660<br /> ...<br /> cleanup_net+0x21a/0x320<br /> <br /> The test sequence that triggers this reliably is:<br /> <br /> 1. Set net.core.bpf_jit_harden=2 (echo 2 &gt; /proc/sys/net/core/bpf_jit_harden)<br /> 2. Run xdp_metadata selftest, which creates a dev-bound-only XDP<br /> program on a veth inside a netns (./test_progs -t xdp_metadata)<br /> 3. cleanup_net -&gt; page fault in __bpf_prog_offload_destroy<br /> <br /> Dev-bound-only programs are unique in that they have an offload structure<br /> but go through the normal JIT path instead of bpf_prog_offload_compile().<br /> This means they are subject to constant blinding&amp;#39;s prog clone-and-replace,<br /> while also having offload-&gt;prog that must stay in sync.<br /> <br /> Fix this by updating offload-&gt;prog in bpf_jit_prog_release_other(),<br /> alongside the existing aux-&gt;prog update. Both are back-pointers to<br /> the prog that must be kept in sync when the prog is replaced.