net: fix fanout UAF in packet_release() via NETDEV_UP race
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.253, 5.15.203, 6.1.168, 6.6.131, 6.12.80, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From ce06b03e60fc19c680d1bf873e779bf11c2fc518 · fixed in ee642b1962caa9aa231c01abbd58bc453ae6b66e; From ce06b03e60fc19c680d1bf873e779bf11c2fc518 · fixed in 42cfd7898eeed290c9fb73f732af1f7d6b0a703e; From ce06b03e60fc19c680d1bf873e779bf11c2fc518 · fixed in 1b4c03f8892d955385c202009af7485364731bb9; From ce06b03e60fc19c680d1bf873e779bf11c2fc518 · fixed in 654386baef228c2992dbf604c819e4c7c35fc71b; From ce06b03e60fc19c680d1bf873e779bf11c2fc518 · fixed in 75fe6db23705a1d55160081f7b37db9665b1880b; From ce06b03e60fc19c680d1bf873e779bf11c2fc518 · fixed in d0c7cdc15fdf8c4f91aca1928e52295d175b6ec6; From ce06b03e60fc19c680d1bf873e779bf11c2fc518 · fixed in ceccbfc6de720ad633519a226715989cfb065af1; From ce06b03e60fc19c680d1bf873e779bf11c2fc518 · fixed in 42156f93d123436f2a27c468f18c966b7e5db796
- Linux Linux
3.1
- KernelLinux
From 3.1.0 · fixed in 5.10.253; From 5.11.0 · fixed in 5.15.203; From 5.16.0 · fixed in 6.1.168; From 6.2.0 · fixed in 6.6.131; From 6.7.0 · fixed in 6.12.80; From 6.13.0 · fixed in 6.18.21; From 6.19.0 · fixed in 6.19.11
References 8
git.kernel.org
- stable/c/ee642b1962caa9aa231c01abbd58bc453ae6b66e
- stable/c/42cfd7898eeed290c9fb73f732af1f7d6b0a703e
- stable/c/1b4c03f8892d955385c202009af7485364731bb9
- stable/c/654386baef228c2992dbf604c819e4c7c35fc71b
- stable/c/75fe6db23705a1d55160081f7b37db9665b1880b
- stable/c/d0c7cdc15fdf8c4f91aca1928e52295d175b6ec6
- stable/c/ceccbfc6de720ad633519a226715989cfb065af1
- stable/c/42156f93d123436f2a27c468f18c966b7e5db796