Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

CVE-2026-64177

Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
19/07/2026
Última modificación:
19/07/2026

Descripción

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phonet/pep: disable BH around forwarded sk_receive_skb()<br /> <br /> The networking receive path is usually run from softirq context, but<br /> protocols that take the socket lock may have packets stored in the<br /> backlog and processed later from process context. In that case<br /> release_sock() -&gt; __release_sock() drops the slock with spin_unlock_bh()<br /> and then calls sk-&gt;sk_backlog_rcv() with bottom halves enabled.<br /> <br /> Typical sk_backlog_rcv handlers process the socket whose backlog is<br /> being drained, so the BH state at entry is irrelevant for the slocks<br /> they touch. pep_do_rcv() is different: when the inbound skb targets an<br /> existing PEP pipe, it forwards the skb to a different *child* socket<br /> via sk_receive_skb(). That helper takes the child slock with<br /> bh_lock_sock_nested(), which is just spin_lock_nested() and assumes BH<br /> is already off. The same child slock therefore ends up acquired with<br /> BH on (process path) and with BH off (softirq path):<br /> <br /> process context softirq context<br /> --------------- ---------------<br /> release_sock(listener) __netif_receive_skb()<br /> __release_sock() phonet_rcv()<br /> spin_unlock_bh() __sk_receive_skb(listener)<br /> [BH now ENABLED] [BH already disabled]<br /> sk_backlog_rcv: sk_backlog_rcv:<br /> pep_do_rcv() pep_do_rcv()<br /> sk_receive_skb(child) sk_receive_skb(child)<br /> bh_lock_sock_nested(child) bh_lock_sock_nested(child)<br /> =&gt; SOFTIRQ-ON-W =&gt; IN-SOFTIRQ-W<br /> <br /> Lockdep flags this as inconsistent lock state, and it can become a real<br /> self-deadlock if a softirq on the same CPU tries to receive to the same<br /> child socket while its slock is held in the BH-enabled path:<br /> <br /> WARNING: inconsistent lock state<br /> inconsistent {SOFTIRQ-ON-W} -&gt; {IN-SOFTIRQ-W} usage.<br /> (slock-AF_PHONET/1){+.?.}-{3:3}, at: __sk_receive_skb+0x1cf/0x900<br /> __sk_receive_skb net/core/sock.c:563<br /> sk_receive_skb include/net/sock.h:2022 [inline]<br /> pep_do_rcv net/phonet/pep.c:675<br /> sk_backlog_rcv include/net/sock.h:1190<br /> __release_sock net/core/sock.c:3216<br /> release_sock net/core/sock.c:3815<br /> pep_sock_accept net/phonet/pep.c:879<br /> <br /> Wrap the forwarded sk_receive_skb() in local_bh_disable() /<br /> local_bh_enable() so the child slock is always acquired with BH off.<br /> local_bh_disable() nests safely on the softirq path.<br /> <br /> Discovered via in-house syzkaller fuzzing; the same root cause also<br /> on the linux-6.1.y syzbot dashboard as extid 44f0626dd6284f02663c.<br /> Reproduced under KASAN + LOCKDEP + PROVE_LOCKING, reproducer:<br /> https://pastebin.com/A3t8xzCR

Impacto