CVE-2026-53094
Vulnérabilité élevée dans Linux (Linux)
Description
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 (BPF_F_XDP_DEV_BOUND_ONLY) undergoes JIT compilation with constant blinding enabled (bpf_jit_harden >= 2), bpf_jit_blind_constants() clones the program. The original prog is then freed in bpf_jit_prog_release_other(), 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, cleanup_net() triggers bpf_dev_bound_netdev_unregister(), which iterates ondev->progs and calls __bpf_prog_offload_destroy(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:__bpf_prog_offload_destroy+0xc/0x80 Call Trace: __bpf_offload_dev_netdev_unregister+0x257/0x350 bpf_dev_bound_netdev_unregister+0x4a/0x90 unregister_netdevice_many_notify+0x2a2/0x660 ... cleanup_net+0x21a/0x320 The test sequence that triggers this reliably is: 1. Set net.core.bpf_jit_harden=2 (echo 2 > /proc/sys/net/core/bpf_jit_harden) 2. Run xdp_metadata selftest, which creates a dev-bound-only XDP program on a veth inside a netns (./test_progs -t xdp_metadata) 3. cleanup_net -> page fault in __bpf_prog_offload_destroy Dev-bound-only programs are unique in that they have an offload structure but go through the normal JIT path instead of bpf_prog_offload_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 bpf_jit_prog_release_other(), alongside the existing aux->prog update. Both are back-pointers to the prog that must be kept in sync when the prog is replaced.
Gravité et risque d'exploitation
CVE-2026-53094 obtient un score CVSS de 7.8/10, soit une gravité élevée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.13 %, ce qui la place devant 2.2 % des CVE référencées.
Que faire ?
- Vérifiez si Linux (versions <=7.0.*, <=6.12.*, 0, 6.18.33, <6.3, <c79f8503d83d4665be461fb9e45e215d0380c67b, 6.12.91, <=6.6.*, <a1aa9ef47c299c5bbc30594d3c2f0589edf908e6, <059525cf18e69a9313baf947d8898c6ee7ca6b65, <a713b72ff88cdab4d5d692908ab1259ada511f4d, 6.3, 6.6.141, 2b3486bc2d237ec345b3942b7be5deabf8c8fed1, 7.1, <=6.18.*, 7.0.10, <=*, <25484c39d1ec82a0368798d956da3de5039b3fe8) est présent sur votre parc.
- Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
- À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
- Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.
Références
- https://git.kernel.org/stable/c/a713b72ff88cdab4d5d692908ab1259ada511f4d
- https://git.kernel.org/stable/c/25484c39d1ec82a0368798d956da3de5039b3fe8
- https://git.kernel.org/stable/c/059525cf18e69a9313baf947d8898c6ee7ca6b65
- https://git.kernel.org/stable/c/c79f8503d83d4665be461fb9e45e215d0380c67b
- https://git.kernel.org/stable/c/a1aa9ef47c299c5bbc30594d3c2f0589edf908e6
