CVE-2026-74468

UNRATEDCVSS · not yet scoredTrending — 5 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:

gpio: pch: use raw_spinlock_t for the register lock

pch_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid.

This was confirmed on a PREEMPT_RT kernel with lockdep (PROVE_RAW_LOCK_NESTING and DEBUG_ATOMIC_SLEEP). A grounded PoC mirrored pch_irq_type()'s locking and drove it through the real genirq carrier irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), i.e. the same __irq_set_trigger() edge that __setup_irq() takes for a requested IRQ. With the original spin_lock_irqsave() edge lockdep reported an invalid wait context, immediately followed by:

BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro] __irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0

Switching the mirrored lock to raw_spinlock_t made both splats go away.

Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, but all of those critical sections only perform MMIO register accesses (ioread32()/iowrite32()) and irq_set_handler_locked(); none of them contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract.

This is the same class of issue and fix as recently addressed for other GPIO controllers, e.g. commit 286533cb14a3 ("gpio: sch: use raw_spinlock_t in the irq startup path") and commit 90f0109019e6 ("gpio: eic-sprd: use raw_spinlock_t in the irq startup path").

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
8%
KEV
Not listed

Published

August 15, 2026

Last Modified

August 19, 2026

Vendor Advisories for CVE-2026-74468(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 18× in last 7d / 18× 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-19 17:36 UTCGHSA enrichment
  2. 2026-08-19 17:34 UTCNVD update
  3. 2026-08-19 17:04 UTCEPSS rescore
  4. 2026-08-19 16:45 UTCGHSA enrichment
  5. 2026-08-19 16:43 UTCMITRE cvelistV5
  6. 2026-08-18 13:49 UTCEPSS rescore
  7. 2026-08-18 13:49 UTCEPSS rescore
  8. 2026-08-17 13:47 UTCEPSS rescore
  9. 2026-08-17 06:25 UTCGHSA enrichment
  10. 2026-08-17 06:22 UTCNVD update
  11. 2026-08-17 05:25 UTCEG score recompute
  12. 2026-08-17 05:25 UTCGHSA enrichment
  13. 2026-08-17 05:24 UTCMITRE cvelistV5
  14. 2026-08-16 14:56 UTCEPSS rescore
  15. 2026-08-16 14:56 UTCEPSS rescore
  16. 2026-08-15 13:27 UTCNVD update
  17. 2026-08-15 12:40 UTCEG score recompute
  18. 2026-08-15 12:37 UTCMITRE cvelistV5first tracked

Frequently asked(4)

What is CVE-2026-74468?
CVE-2026-74468 is a publicly disclosed vulnerability published on August 15, 2026. In the Linux kernel, the following vulnerability has been resolved: gpio: pch: use rawspinlockt for the register lock pchirqtype() is registered as the irqchip .irqset_type callback and takes chip->spinlock with spinlockirqsave(). This callback is reached from setupirq() -> irqsettrigger() ->…
When was CVE-2026-74468 disclosed?
CVE-2026-74468 was first published in the National Vulnerability Database on August 15, 2026, with the most recent update on August 19, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-74468 actively exploited?
CVE-2026-74468 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 92.5% of all scored CVEs.
How do I remediate CVE-2026-74468?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-74468, 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-74468

Explore →

Is Your Infrastructure Affected by CVE-2026-74468?

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