Re: [PATCH net] phonet/pep: disable BH around forwarded sk_receive_skb()

[Eric Dumazet]

On Wed, May 20, 2026 at 5:03 AM Rémi Denis-Courmont <remi@xxxxxxxxxx> wrote:
>
>
>
> Le 19 mai 2026 20:26:33 GMT+03:00, Zijing Yin <yzjaurora@xxxxxxxxx> a écrit :
> >The networking receive path is usually run from softirq context, but
> >protocols that take the socket lock may have packets stored in the
> >backlog and processed later from process context. In that case
> >release_sock() -> __release_sock() drops the slock with spin_unlock_bh()
> >and then calls sk->sk_backlog_rcv() with bottom halves enabled.
> >
> >Typical sk_backlog_rcv handlers process the socket whose backlog is
> >being drained, so the BH state at entry is irrelevant for the slocks
> >they touch. pep_do_rcv() is different: when the inbound skb targets an
> >existing PEP pipe, it forwards the skb to a different *child* socket
> >via sk_receive_skb(). That helper takes the child slock with
> >bh_lock_sock_nested(), which is just spin_lock_nested() and assumes BH
> >is already off. The same child slock therefore ends up acquired with
> >BH on (process path) and with BH off (softirq path):
> >
> >  process context                   softirq context
> >  ---------------                   ---------------
> >  release_sock(listener)            __netif_receive_skb()
> >   __release_sock()                  phonet_rcv()
> >    spin_unlock_bh()                  __sk_receive_skb(listener)
> >    [BH now ENABLED]                  [BH already disabled]
> >    sk_backlog_rcv:                   sk_backlog_rcv:
> >     pep_do_rcv()                      pep_do_rcv()
> >      sk_receive_skb(child)             sk_receive_skb(child)
> >       bh_lock_sock_nested(child)        bh_lock_sock_nested(child)
> >       => SOFTIRQ-ON-W                   => IN-SOFTIRQ-W
> >
> >Lockdep flags this as inconsistent lock state, and it can become a real
> >self-deadlock if a softirq on the same CPU tries to receive to the same
> >child socket while its slock is held in the BH-enabled path:
> >
> >  WARNING: inconsistent lock state
> >  inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
> >   (slock-AF_PHONET/1){+.?.}-{3:3}, at: __sk_receive_skb+0x1cf/0x900
> >    __sk_receive_skb              net/core/sock.c:563
> >    sk_receive_skb                include/net/sock.h:2022 [inline]
> >    pep_do_rcv                    net/phonet/pep.c:675
> >    sk_backlog_rcv                include/net/sock.h:1190
> >    __release_sock                net/core/sock.c:3216
> >    release_sock                  net/core/sock.c:3815
> >    pep_sock_accept               net/phonet/pep.c:879
> >
> >Wrap the forwarded sk_receive_skb() in local_bh_disable() /
> >local_bh_enable() so the child slock is always acquired with BH off.
> >local_bh_disable() nests safely on the softirq path.
> >
> >Discovered via in-house syzkaller fuzzing; the same root cause also
> >on the linux-6.1.y syzbot dashboard as extid 44f0626dd6284f02663c.
> >Reproduced under KASAN + LOCKDEP + PROVE_LOCKING, reproducer:
> >https://pastebin.com/A3t8xzCR
> >
> >Fixes: 9641458d3ec4 ("Phonet: Pipe End Point for Phonet Pipes protocol")
> >Link: https://syzkaller.appspot.com/bug?extid=44f0626dd6284f02663c
> >Cc: stable@xxxxxxxxxxxxxxx
> >Signed-off-by: Zijing Yin <yzjaurora@xxxxxxxxx>
>
> Acked-by: Rémi Denis-Courmont <remi@xxxxxxxxxx>

Reported-by: syzbot+9f4a135646b66c509935@xxxxxxxxxxxxxxxxxxxxxxxxx
Reviewed-by: Eric Dumazet <edumazet@xxxxxxxxxx>

Thanks!