Answer in brief
CVE-2026-80548 records a Unknown severity vulnerability in s390/vfio_ccw: Selectively expand io_mutex. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=4f76617378ee97c557b526cb58d3c61eb0a9c963 <f72a51810d49411bd8cad0c2df8592320a2fe5cc || >=4f76617378ee97c557b526cb58d3c61eb0a9c963 <2ba9efdf9ebedc4e54df4b56aa3b43a65f7967cd || >=4f76617378ee97c557b526cb58d3c61eb0a9c963 <b6aecea4b2b246f9fbd98a5712daa1193a60818e || >=4f76617378ee97c557b526cb58d3c61eb0a9c963 <2a5ac0c0f1f7da33929211a2e41911bf72ee35d8 || >=4f76617378ee97c557b526cb58d3c61eb0a9c963 <34f4feff3e90bd09308fad0974e97113b23b812a | f72a51810d49411bd8cad0c2df8592320a2fe5cc, 2ba9efdf9ebedc4e54df4b56aa3b43a65f7967cd, b6aecea4b2b246f9fbd98a5712daa1193a60818e, 2a5ac0c0f1f7da33929211a2e41911bf72ee35d8, 34f4feff3e90bd09308fad0974e97113b23b812a |
| Linux/Linuxgeneric | 5.2 | Not reported |
Published upstream
Aug 26, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 26, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 26, 2026
In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Selectively expand io_mutex The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share. With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself.
Quoted source text, attributed separately from HOL analysis.