CVE-2026-74686

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rqspinlock: Reset tail when preserving queue on deadlock<br /> <br /> Currently, the destruction of the waiter queue is suppressed for<br /> rqspinlock in cases where a deadlock is detected. Deadlock checks happen<br /> relatively frequently (on entry for AA, within 1ms for ABBA), and waiter<br /> threads may not be involved in locking scenarios involving deadlocks.<br /> Thus, it is useful to not flush the queue and let other waiters take a<br /> stab at acquiring the lock after we detect a deadlock and exit.<br /> <br /> However, we need to follow the same logic as what we did previously for<br /> the waitq_timeout label: reset the tail, and if we cannot, signal the<br /> next waiter appropriately. In case of deadlocks, this signal would just<br /> mark the MCS node as unlocked, and in case of timeouts, it would signal<br /> RES_TIMEOUT_VAL. The difference thus is in the value propagated, which<br /> decides whether the queue remains active or gets flushed.<br /> <br /> Not doing the tail reset, and waiting for the next waiter can lead to<br /> cases where we are the final waiter, and thus no next waiter arrives,<br /> leading to intermittent stalls in this path. Once the next waiter does<br /> join, we will be unblocked. In the theoretical case when the next waiter<br /> never joins, we risk stalling indefinitely.<br /> <br /> This can only happen for ABBA deadlocks, since entry into the wait queue<br /> is guarded with AA checks. A precise sequence of executions leading up<br /> to this scenario can be:<br /> <br /> CPU 0 holds lock A.<br /> CPU 1 holds lock B.<br /> CPU 2 attempts lock B, becomes the pending waiter for B.<br /> CPU 0 attempts lock B. B has locked+pending bits set, thus CPU 0 queues.<br /> CPU 1 attempts lock A.<br /> CPU 0 detects an ABBA deadlock.<br /> <br /> Once deadlock detection happens for CPU 0, it will sit waiting for the<br /> next waiter in the queue to populate node-&gt;next, which will experience<br /> delays until such a waiter arrives.<br /> <br /> Fix this by adjusting the logic for the check for deadlocks preceding<br /> the waitq_timeout label. It would make sense to consolidate code for<br /> both cases and use &amp;#39;ret&amp;#39; to distinguish the value being propagated, but<br /> that is left as an exercise for a future refactoring task to avoid diff<br /> noise in this patch.