Answer in brief
CVE-2026-53124 records a Unknown severity vulnerability in ublk: reset per-IO canceled flag on each fetch. 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 | >=728cbac5fe219d3b8a21a0688a08f2b7f8aeda2b <de05e37d02f3f33ebca4967164e54f5fea809d86 || >=728cbac5fe219d3b8a21a0688a08f2b7f8aeda2b <63335e5a67d89bb7cb9b023bbb3785896587a648 || >=728cbac5fe219d3b8a21a0688a08f2b7f8aeda2b <0842186d2c4e67d2f8c8c2d1d779e8acffd41b5b || 42ea64e01c96e594fb4f80c54dfe4f934d008a6e || >=6.14.6 <6.15 | de05e37d02f3f33ebca4967164e54f5fea809d86, 63335e5a67d89bb7cb9b023bbb3785896587a648, 0842186d2c4e67d2f8c8c2d1d779e8acffd41b5b, 6.15 |
| Linux/Linuxgeneric | 6.15 | Not reported |
Published upstream
Jun 24, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jun 24, 2026
In the Linux kernel, the following vulnerability has been resolved: ublk: reset per-IO canceled flag on each fetch If a ublk server starts recovering devices but dies before issuing fetch commands for all IOs, cancellation of the fetch commands that were successfully issued may never complete. This is because the per-IO canceled flag can remain set even after the fetch for that IO has been submitted - the per-IO canceled flags for all IOs in a queue are reset together only once all IOs for that queue have been fetched. So if a nonempty proper subset of the IOs for a queue are fetched when the ublk server dies, the IOs in that subset will never successfully be canceled, as their canceled flags remain set, and this prevents ublk_cancel_cmd from actually calling io_uring_cmd_done on the commands, despite the fact that they are outstanding. Fix this by resetting the per-IO cancel flags immediately when each IO is fetched instead of waiting for all IOs for the queue (which may never happen).
Quoted source text, attributed separately from HOL analysis.