CVE-2026-64206

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: cancel pending_rx_work before taking conn-&gt;lock<br /> <br /> l2cap_conn_del() takes conn-&gt;lock and then calls cancel_work_sync() for<br /> pending_rx_work. process_pending_rx() takes the same mutex, so teardown<br /> can deadlock against the worker it is flushing.<br /> <br /> This issue was found by our static analysis tool and then manually<br /> reviewed against the current tree.<br /> <br /> The grounded PoC kept the l2cap_conn_ready() -&gt; queue_work(...,<br /> &amp;conn-&gt;pending_rx_work) submit path, the l2cap_conn_del() -&gt;<br /> cancel_work_sync(&amp;conn-&gt;pending_rx_work) teardown path, and the<br /> process_pending_rx() -&gt; mutex_lock(&amp;conn-&gt;lock) worker edge. Lockdep<br /> <br /> WARNING: possible circular locking dependency detected<br /> process_pending_rx+0x21/0x2a [vuln_msv]<br /> l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv]<br /> *** DEADLOCK ***<br /> <br /> Cancel pending_rx_work before taking conn-&gt;lock, matching the existing<br /> lock-before-drain ordering used for the two delayed works in the same<br /> teardown path. The pending_rx queue is still purged after the work has<br /> been cancelled and conn-&gt;lock has been acquired.