CVE-2026-74686

UNRATEDCVSS · not yet scoredTrending — 3 sources updated this week
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No CVSS published and no exploitation signals yet
CISA-KEV: Not listedEPSS PROB: 0%CVSS v2: Exploit: None knownExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

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 for the next waiter can lead to cases where we are the final waiter, and thus no next waiter arrives, leading to intermittent stalls in this path. Once the next waiter does join, we will be unblocked. In the theoretical case when the next waiter never joins, we risk stalling indefinitely.

This can only happen for ABBA deadlocks, since entry into the wait queue is guarded with AA checks. A precise sequence of executions leading up to this scenario can be:

CPU 0 holds lock A. CPU 1 holds lock B. CPU 2 attempts lock B, becomes the pending waiter for B. CPU 0 attempts lock B. B has locked+pending bits set, thus CPU 0 queues. CPU 1 attempts lock A. CPU 0 detects an ABBA deadlock.

Once deadlock detection happens for CPU 0, it will sit waiting for the next waiter in the queue to populate node->next, which will experience delays until such a waiter arrives.

Fix this by adjusting the logic for the check for deadlocks preceding the waitq_timeout label. It would make sense to consolidate code for both cases and use 'ret' to distinguish the value being propagated, but that is left as an exercise for a future refactoring task to avoid diff noise in this patch.

CVSS v3
EchelonGraph score
Not yet assessedNo source has published severity data for this CVE yet — no CVSS score from NVD or a CNA, no GitHub advisory, and it is not in CISA KEV. This is not a rating of zero; we cannot assess it yet.
EG Score
EG Risk
EPSS PROB
0%
EPSS %ILE
9%
KEV
Not listed

Published

August 22, 2026

Last Modified

August 22, 2026

Vendor Advisories for CVE-2026-74686(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 8× in last 7d / 11× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-08-30 01:22 UTCEPSS rescore
  2. 2026-08-28 21:42 UTCEPSS rescore
  3. 2026-08-28 17:34 UTCGHSA enrichment
  4. 2026-08-26 14:47 UTCEPSS rescore
  5. 2026-08-25 16:58 UTCEG score recompute
  6. 2026-08-25 16:57 UTCGHSA enrichment
  7. 2026-08-25 13:49 UTCEPSS rescore
  8. 2026-08-24 14:18 UTCEPSS rescore
  9. 2026-08-22 16:24 UTCNVD update
  10. 2026-08-22 15:39 UTCEG score recompute
  11. 2026-08-22 15:35 UTCMITRE cvelistV5first tracked

Frequently asked(4)

What is CVE-2026-74686?
CVE-2026-74686 is a publicly disclosed vulnerability published on August 22, 2026. 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…
When was CVE-2026-74686 disclosed?
CVE-2026-74686 was first published in the National Vulnerability Database on August 22, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-74686 actively exploited?
CVE-2026-74686 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0% probability of exploitation in the next 30 days, which ranks it in the top 91.4% of all scored CVEs.
How do I remediate CVE-2026-74686?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-74686, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-74686

Explore →

Is Your Infrastructure Affected by CVE-2026-74686?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.