CVSS 3.1 base metricsRed raises the risk · green lowers it
Attack vector
LocalAV:L
Attack complexity
LowAC:L
Privileges required
LowPR:L
User interaction
NoneUI:N
Scope
UnchangedS:U
Confidentiality
NoneC:N
Integrity
NoneI:N
Availability
HighA:H
Updates that fix it
0 KBs
No KB listed
No KB update is listed in the collected MSRC record. Check the MSRC advisory for product releases and other remedies.
Affected products
Open Source Software
1 affected product
azl3 kernel 6.6.157.1-1 on Azure Linux 3.0
What changed
Detection template: Unknown: detection-template evidence is incomplete or retained → No Nuclei template listed
Detection template: No Nuclei template listed → Unknown: detection-template evidence is incomplete or retained
Detection template: Unknown: detection-template evidence is incomplete or retained → No Nuclei template listed
Detection template: No Nuclei template listed → Unknown: detection-template evidence is incomplete or retained
Detection template: No Nuclei template listed · Customer action: Required: apply the update → Required: follow the MSRC remediation guidance · Public disclosure: No → Unknown: not stated by MSRC · Exploitation detected: Not reported by MSRC → Unknown: not stated by MSRC
Detection template: Unknown: exploit-code evidence is incomplete or retained → No Nuclei template listed · CISA KEV: Unknown: catalog evidence is incomplete or retained → Not listed in the collected catalog
Detection template: No Nuclei template listed → Unknown: exploit-code evidence is incomplete or retained · CISA KEV: Not listed in the collected catalog → Unknown: catalog evidence is incomplete or retained
Page history
Changes are dated when recorded; day views use the last saved version from that UTC day, and citations stay fixed.
CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.
No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.
cve-program · CVE-2026-98094
Published
staging: fbtft: make dirty_lock IRQ-safe
In the Linux kernel, the following vulnerability has been resolved:
staging: fbtft: make dirty_lock IRQ-safe
fbtft_mkdirty() can be reached from the fbcon rendering path while
processing printk() in hardirq context. Meanwhile, dirty_lock is also
taken by fbtft_deferred_io() in workqueue context with local interrupts
enabled.
Lockdep reports a possible IRQ lock inversion involving dirty_lock and
console_owner. A hardirq can interrupt a CPU holding dirty_lock and
enter the console rendering path, which can attempt to acquire
dirty_lock again.
The following lockdep report was observed on an RK3566 system with
CONFIG_PROVE_LOCKING enabled:
WARNING: possible irq lock inversion dependency detected
swapper/2/0 just changed the state of lock:
(console_owner){-...}-{0:0}
but this lock took another, HARDIRQ-unsafe lock in the past:
(&par->dirty_lock){+.+.}-{2:2}
CPU0 CPU1
---- ----
lock(&par->dirty_lock);
local_irq_disable();
lock(console_owner);
lock(&par->dirty_lock);
<Interrupt>
lock(console_owner);
*** DEADLOCK ***
Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for
fbtft_deferred_io(). They only access the dirty line range, so the
IRQ-off regions remain short.
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.