CVE-2026-22995: ublk: fix use-after-free in ublk_partition_scan_work
In the Linux kernel, the following vulnerability has been resolved:
ublk: fix use-after-free in ublk_partition_scan_work
A race condition exists between the async partition scan work and device
teardown that can lead to a use-after-free of ub->ub_disk:
1. ublk_ctrl_start_dev() schedules partition_scan_work after add_disk()
2. ublk_stop_dev() calls ublk_stop_dev_unlocked() which does:
- del_gendisk(ub->ub_disk)
- ublk_detach_disk() sets ub->ub_disk = NULL
- put_disk() which may free the disk
3. The worker ublk_partition_scan_work() then dereferences ub->ub_disk
leading to UAF
Fix this by using ublk_get_disk()/ublk_put_disk() in the worker to hold
a reference to the disk during the partition scan. The spinlock in
ublk_get_disk() synchronizes with ublk_detach_disk() ensuring the worker
either gets a valid reference or sees NULL and exits early.
Also change flush_work() to cancel_work_sync() to avoid running the
partition scan work unnecessarily when the disk is already detached.
Security readout for executives and security teams
Plain-English summary
CVE-2026-22995 is a Linux kernel use-after-free bug in the ublk userspace block device code. A race during device startup, partition scanning, and teardown can leave background work using a disk object after it was detached or freed. Public sources do not provide CVSS, business impact, or distribution-specific exposure details.
Executive priority
Treat as an inventory and patch-tracking item until severity is clarified. It is kernel memory-safety code, but current public evidence lacks exploitation or impact scoring.
Technical view
The issue is in ublk_partition_scan_work. After add_disk schedules asynchronous partition scan work, ublk_stop_dev can delete and detach ub->ub_disk, then put_disk may free it. The worker can later dereference ub->ub_disk. The fix takes a disk reference with ublk_get_disk/ublk_put_disk and changes flush_work to cancel_work_sync.
Likely exposure
Likely limited to Linux systems running affected kernel revisions with ublk functionality present or enabled. The bundle does not identify affected distributions, configurations, or whether ordinary unprivileged users can reach the vulnerable path.
Exploitation context
The source bundle does not report active exploitation, and KEV is false. It describes a kernel race condition, but does not provide exploitability, privilege requirements, reliability, or real-world attack evidence.
Researcher notes
Focus validation on the ublk disk lifecycle race around partition scan work and teardown. The provided fix relies on synchronized reference acquisition and canceling unnecessary work after detach. Avoid assuming distribution impact without vendor mapping.
Mitigation direction
Apply Linux kernel updates that include the referenced stable fixes.
Track distribution advisories for backported fixed kernel packages.
If no update is available, ask the vendor for supported mitigation guidance.
Prioritize systems where ublk is enabled or used operationally.
Validation and detection
Inventory Linux kernel versions across affected fleets.
Determine whether ublk support is present, enabled, or used.
Compare vendor kernel packages against the referenced upstream stable fixes.
Review distribution security advisories for CVE-2026-22995 coverage.
Confirm patched systems are running the updated kernel after reboot.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-22995 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
3Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jan 23, 2026, 15:24 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.