Skip to main content

Linux Kernel EUVDEUVD-2026-38992

| CVE-2026-53124 MEDIUM
2026-06-24 Linux GHSA-xq85-jg4p-xf7w
Information Disclosure Linux Apple Red Hat Suse
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
4.7 MEDIUM

AC:H reflects the specific timing requirement (server must die during partial-fetch window); PR:L for local low-privilege access; A:H for IO hang; no C or I impact.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative
Red Hat
5.5 LOW
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 23, 2026 - 21:11 vuln.today
CVSS changed
Jul 23, 2026 - 21:07 NVD
5.5 (MEDIUM)
Patch available
Jun 24, 2026 - 18:02 EUVD
CVE Published
Jun 24, 2026 - 16:30 nvd
MEDIUM 5.5
CVE Published
Jun 24, 2026 - 16:30 cve.org
UNKNOWN (no severity yet)

DescriptionNVD

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

AnalysisAI

Availability loss in the Linux kernel ublk (userspace block device) subsystem can permanently hang IO commands when a ublk recovery server dies before issuing fetch commands for all IOs in a queue. The per-IO canceled flag, once set, is only cleared when every IO in the queue is fetched - if the server crashes mid-recovery, surviving IOs with set canceled flags can never be completed because ublk_cancel_cmd is blocked from calling io_uring_cmd_done. This results in a denial-of-service condition affecting systems using ublk-based userspace block devices. No public exploit has been identified at time of analysis, and EPSS is 0.14% (4th percentile), consistent with a low-exploitation-probability kernel logic flaw requiring specific local conditions.

Technical ContextAI

ublk is a Linux kernel framework (introduced in kernel 5.19) that allows userspace programs to implement block devices via io_uring commands. CPE data identifies the affected product as cpe:2.3:a:linux:linux. The vulnerability is a lifecycle management logic error in the IO cancellation path of the ublk driver: the per-IO canceled flag is reset en masse only after all IOs in a queue have been fetched, rather than atomically per IO at fetch time. The root cause is not formally classified by a CWE, but the pattern matches an improper state management or incorrect synchronization issue - specifically, the flag reset is incorrectly gated on a collective condition that may never be satisfied. The io_uring subsystem is involved as the command delivery mechanism, and the failure mode is that io_uring_cmd_done is never called for affected commands, causing them to remain pending indefinitely.

RemediationAI

The primary fix is to upgrade to a patched Linux kernel version: 6.15 or later, 7.0.10 or later, or 7.1 or later. The upstream patches are available at https://git.kernel.org/stable/c/0842186d2c4e67d2f8c8c2d1d779e8acffd41b5b and https://git.kernel.org/stable/c/63335e5a67d89bb7cb9b023bbb3785896587a648. Ubuntu users should apply updates per USN-8568-1 (https://ubuntu.com/security/notices/USN-8568-1) and USN-8566-1 (https://ubuntu.com/security/notices/USN-8566-1). As a compensating control on systems that cannot immediately patch, disabling or avoiding use of the ublk subsystem eliminates exposure - specifically, not deploying ublk-based userspace block device servers prevents the vulnerable code path from being reachable. Systems not using ublk at all are not affected by this vulnerability.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Performance Computing 15 SP7 Not-Affected

Share

EUVD-2026-38992 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy