A Linux Kernel flaw deadlock found in the BPF. Existing reproducer allows to trigger a lockdep warning. Tested with kernel v5.15.25 and v5.19. The fail happens in the function sock_hash_delete_elem: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&htab->buckets[i].lock); local_irq_disable(); lock(&rq->__lock); lock(&htab->buckets[i].lock); <Interrupt> lock(&rq->__lock); *** DEADLOCK ***
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2023-0160
Hi Alex, (In reply to Alex from comment #0) > A Linux Kernel flaw deadlock found in the BPF. Existing reproducer allows to > trigger a lockdep warning. Tested with kernel v5.15.25 and v5.19. The fail > happens in the function sock_hash_delete_elem: > > Possible interrupt unsafe locking scenario: > > CPU0 CPU1 > ---- ---- > lock(&htab->buckets[i].lock); > local_irq_disable(); > lock(&rq->__lock); > lock(&htab->buckets[i].lock); > <Interrupt> > lock(&rq->__lock); > > *** DEADLOCK *** Are there any cross-references for this, i.e. where it originates from and was it ever fixed upstream? I'm asking to properly track the CVE in Debian. Regards, Salvatore
https://lore.kernel.org/lkml/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com/ might be the relevant report upstream.
In reply to comment #6: > Hi Alex, > > (In reply to Alex from comment #0) > > A Linux Kernel flaw deadlock found in the BPF. Existing reproducer allows to > > trigger a lockdep warning. Tested with kernel v5.15.25 and v5.19. The fail > > happens in the function sock_hash_delete_elem: > > > > Possible interrupt unsafe locking scenario: > > > > CPU0 CPU1 > > ---- ---- > > lock(&htab->buckets[i].lock); > > local_irq_disable(); > > lock(&rq->__lock); > > lock(&htab->buckets[i].lock); > > <Interrupt> > > lock(&rq->__lock); > > > > *** DEADLOCK *** > > Are there any cross-references for this, i.e. where it originates > from and was it ever fixed upstream? > > I'm asking to properly track the CVE in Debian. > > Regards, > Salvatore Hi Salvatore, Yes, currently the only discussions happens (and likely patch not ready yet): https://lore.kernel.org/all/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com/ You may ask reporter Hsin-Wei Hung to inform you when it ready. Or ask John Fastabend , because he said (in the same discussion): "Thanks, I'll take a look.". Alex
Got reply from the reporter regarding this one: Hi Alex, The bug was fixed in ed17aa92dc56 ("bpf, sockmap: Revert buggy deadlock fix in the sockhash and sockmap") The fix basically disables hardirq instead of only softirq in the critical section in delete() in sockmap/sockhash since an element can be deleted from an eBPF program in the interrupt context (hardirq). Thanks, Hsin-Wei
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2223191]
This was fixed for Fedora with the 6.2.15 stable kernel updates.
Unfortunately, ed17aa92dc56 ("bpf, sockmap: Revert buggy deadlock fix in the sockhash and sockmap") was reverted upstream in 8c5c2a4898e3 ("bpf, sockmap: Revert buggy deadlock fix in the sockhash and sockmap"), which was also backported as part of the 6.2.15 stable kernel update (commit 3cd6ab3b5451).