dibs: initialise dibs->lock in dibs_dev_alloc()
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 6.18.45, 7.1.9
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: total
Summary
In the Linux kernel, the following vulnerability has been resolved: dibs: initialise dibs->lock in dibs_dev_alloc() dibs->lock is initialised by dibs_dev_add(), but a dibs device can already take interrupts before that call: ism_probe() runs ism_dev_init(), and hence request_irq(), before it calls dibs_dev_add(). No client can have registered a dmb at that point, so no dmb interrupt can occur, but a GID event interrupt can, and ism_handle_irq() takes dibs->lock unconditionally on entry, before it inspects anything else. Initialise the lock in dibs_dev_alloc() instead, so that it is valid as soon as a driver can publish the device to its interrupt handler.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From cc21191b584c6f7836b0f10774f8278b7cbfba10 · fixed in fe79571f40434b257d68cbfb7b3ae93a794d8a11; From cc21191b584c6f7836b0f10774f8278b7cbfba10 · fixed in 2926031acba100d0c18fcfaa7a2ed29609318848; From cc21191b584c6f7836b0f10774f8278b7cbfba10 · fixed in c27e360545373b7aee9862a5beef3b9fb3df0c25
- Linux Linux
6.18
- KernelLinux
From 6.18.0 · fixed in 6.18.45; From 6.19.0 · fixed in 7.1.9