0.0
NA
CVE-2026-53124
ublk: reset per-IO canceled flag on each fetch
Description

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).

INFO

Published Date :

June 24, 2026, 5:17 p.m.

Last Modified :

July 14, 2026, 3:26 p.m.

Remotely Exploit :

No

Source :

416baaa9-dc9f-4396-8d5f-8c081fb06d67
Affected Products

The following products are affected by CVE-2026-53124 vulnerability. Even if cvefeed.io is aware of the exact versions of the products that are affected, the information is not represented in the table below.

ID Vendor Product Action
1 Linux linux_kernel
Solution
Reset per-IO canceled flags immediately upon fetch to ensure timely cancellation.
  • Apply the Linux kernel patch for the ublk: reset per-IO canceled flag issue.
  • Ensure all submitted IOs are properly canceled upon fetch.
  • Test device recovery and IO cancellation logic.
References to Advisories, Solutions, and Tools

Here, you will find a curated list of external links that provide in-depth information, practical solutions, and valuable tools related to CVE-2026-53124.

URL Resource
https://git.kernel.org/stable/c/0842186d2c4e67d2f8c8c2d1d779e8acffd41b5b
https://git.kernel.org/stable/c/63335e5a67d89bb7cb9b023bbb3785896587a648
CWE - Common Weakness Enumeration

While CVE identifies specific instances of vulnerabilities, CWE categorizes the common flaws or weaknesses that can lead to vulnerabilities. CVE-2026-53124 is associated with the following CWEs:

Common Attack Pattern Enumeration and Classification (CAPEC)

Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2026-53124 weaknesses.

We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).

Results are limited to the first 15 repositories due to potential performance issues.

The following list is the news that have been mention CVE-2026-53124 vulnerability anywhere in the article.

The following table lists the changes that have been made to the CVE-2026-53124 vulnerability over time.

Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.

  • New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Jun. 24, 2026

    Action Type Old Value New Value
    Added Affected [{'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '728cbac5fe219d3b8a21a0688a08f2b7f8aeda2b', 'lessThan': '63335e5a67d89bb7cb9b023bbb3785896587a648', 'versionType': 'git'}, {'status': 'affected', 'version': '728cbac5fe219d3b8a21a0688a08f2b7f8aeda2b', 'lessThan': '0842186d2c4e67d2f8c8c2d1d779e8acffd41b5b', 'versionType': 'git'}, {'status': 'affected', 'version': '42ea64e01c96e594fb4f80c54dfe4f934d008a6e', 'versionType': 'git'}, {'status': 'affected', 'version': '6.14.6', 'lessThan': '6.15', 'versionType': 'semver'}], 'programFiles': ['drivers/block/ublk_drv.c'], 'defaultStatus': 'unaffected'}, {'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '6.15'}, {'status': 'unaffected', 'version': '0', 'lessThan': '6.15', 'versionType': 'semver'}, {'status': 'unaffected', 'version': '7.0.10', 'versionType': 'semver', 'lessThanOrEqual': '7.0.*'}, {'status': 'unaffected', 'version': '7.1', 'versionType': 'original_commit_for_fix', 'lessThanOrEqual': '*'}], 'programFiles': ['drivers/block/ublk_drv.c'], 'defaultStatus': 'affected'}]
    Added Description 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).
    Added Reference https://git.kernel.org/stable/c/0842186d2c4e67d2f8c8c2d1d779e8acffd41b5b
    Added Reference https://git.kernel.org/stable/c/63335e5a67d89bb7cb9b023bbb3785896587a648
EPSS is a daily estimate of the probability of exploitation activity being observed over the next 30 days. Following chart shows the EPSS score history of the vulnerability.