CVE-2026-74686

/// Technical description

In the Linux kernel, the following vulnerability has been resolved:

rqspinlock: Reset tail when preserving queue on deadlock

Currently, the destruction of the waiter queue is suppressed for

rqspinlock in cases where a deadlock is detected. Deadlock checks happen

relatively frequently (on entry for AA, within 1ms for ABBA), and waiter

threads may not be involved in locking scenarios involving deadlocks.

Thus, it is useful to not flush the queue and let other waiters take a

stab at acquiring the lock after we detect a deadlock and exit.

However, we need to follow the same logic as what we did previously for

the waitq_timeout label: reset the tail, and if we cannot, signal the

next waiter appropriately. In case of deadlocks, this signal would just

mark the MCS node as unlocked, and in case of timeouts, it would signal

RES_TIMEOUT_VAL. The difference thus is in the value propagated, which

decides whether the queue remains active or gets flushed.

Not doing the tail reset, and waiting fo

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References