GHSA-2JWW-55PG-7C53
Vulnerability from github – Published: 2026-10-23 15:31 – Updated: 2026-10-23 15:31In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: Disable the V3D interrupt across runtime suspend
vc4_irq_disable() masks the V3D interrupt sources and then calls synchronize_irq() before the V3D is powered down. However, by itself, this is not enough to quiesce the interrupt handler.
synchronize_irq() waits for handlers that have already set IRQD_IRQ_INPROGRESS, and for irqchips reporting IRQCHIP_STATE_ACTIVE. A GIC interrupt chip is able to mark an interrupt active as soon as a CPU acknowledges it, so there these checks cover the whole dispatch path. On RPi 0-3, however, the interrupt controller is ARMCTRL, which has no active state. A CPU that has read the hwirq out of the pending register but has not yet reached handle_level_irq() stays invisible to synchronize_irq().
During a power transition, vc4_irq() may therefore run after the power domain is off, where every V3D register read will return 0xdeadbeef. 0xdeadbeef has FLDONE, FRDONE and OUTOMEM set. This problem doesn't trigger NULL pointer dereference issues only because the functions vc4_irq_finish_bin_job() and vc4_irq_finish_render_job() return early when there is no job pointer, but OUTOMEM is still able to schedule vc4_overflow_mem_work() after vc4_irq_disable() has already cancelled it.
Therefore, fix the spurious interrupts by disabling the interrupt line across the PM transition. To preserve the enable/disable balance, move vc4_irq_install() and request the IRQ line disabled before the first runtime resume.
{
"affected": [],
"aliases": [
"CVE-2026-98946"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-23T13:17:15Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vc4: Disable the V3D interrupt across runtime suspend\n\nvc4_irq_disable() masks the V3D interrupt sources and then calls\nsynchronize_irq() before the V3D is powered down. However, by itself,\nthis is not enough to quiesce the interrupt handler.\n\nsynchronize_irq() waits for handlers that have already set\nIRQD_IRQ_INPROGRESS, and for irqchips reporting IRQCHIP_STATE_ACTIVE.\nA GIC interrupt chip is able to mark an interrupt active as soon as a\nCPU acknowledges it, so there these checks cover the whole dispatch path.\nOn RPi 0-3, however, the interrupt controller is ARMCTRL, which has no\nactive state. A CPU that has read the hwirq out of the pending register\nbut has not yet reached handle_level_irq() stays invisible to\nsynchronize_irq().\n\nDuring a power transition, vc4_irq() may therefore run after the power\ndomain is off, where every V3D register read will return 0xdeadbeef.\n0xdeadbeef has FLDONE, FRDONE and OUTOMEM set. This problem doesn\u0027t\ntrigger NULL pointer dereference issues only because the functions\nvc4_irq_finish_bin_job() and vc4_irq_finish_render_job() return early\nwhen there is no job pointer, but OUTOMEM is still able to schedule\nvc4_overflow_mem_work() after vc4_irq_disable() has already cancelled it.\n\nTherefore, fix the spurious interrupts by disabling the interrupt line\nacross the PM transition. To preserve the enable/disable balance, move\nvc4_irq_install() and request the IRQ line disabled before the first\nruntime resume.",
"id": "GHSA-2jww-55pg-7c53",
"modified": "2026-10-23T15:31:32Z",
"published": "2026-10-23T15:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98946"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6abc8e4dcfbc1d26a94c0ac037dfb3716f686b1f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e81402c3d42041356cb7978510ebab997bc8d411"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.