Cloudanix VulnDB

CVE-2026-90277

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux storage management could let the system accidentally use memory after it has already been released, which might cause crashes or open security holes on servers that use software RAID.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in llbitmap_create() where mddev->bitmap is published before llbitmap_read_sb() succeeds; on read_sb failure the cleanup drops bitmap_info.mutex then frees the llbitmap without clearing the pointer, allowing mutex-protected readers (/proc/mdstat etc.) to dereference a stale freed pointer.

Why it matters to the business

Linux systems using md RAID may suffer kernel crashes, memory corruption, or brief storage unavailability when bitmap creation fails on an md device; the low exploitability and absence from known campaigns limit immediate operational risk but still require timely patching on storage servers.

How an attack unfolds

An attacker with local access would attempt to force llbitmap_read_sb() failure during md device creation or reconfiguration, then race a reader thread or process that walks bitmap stats under bitmap_info.mutex to trigger the use-after-free; no public exploits or threat-actor campaigns are known.

How to fix it

Upgrade the Linux kernel to a version containing the fix that clears mddev->bitmap while still holding bitmap_info.mutex before freeing the failed llbitmap.

How to confirm the fix worked

Confirm the running kernel contains the corrected llbitmap_create() cleanup sequence; inspect source or changelog for the mutex-protected pointer clear before kfree; re-test md device creation with forced read_sb failures.

Typical attack path

  1. Obtain local code execution on a system with md RAID
  2. Trigger bitmap creation that will fail inside llbitmap_read_sb()
  3. Race a concurrent reader of /proc/mdstat or equivalent bitmap stat collector
  4. Exploit the resulting use-after-free for memory corruption or denial of service

How to detect it

Search kernel logs (dmesg, journalctl) for oops or warnings mentioning md bitmap, llbitmap, or use-after-free near bitmap_info.mutex; look for unexpected md device creation failures coinciding with /proc/mdstat reads.

What your security team should do

  • Apply the corrected kernel package as soon as it is available in your distribution
  • Prioritize systems that expose md devices to untrusted local users
  • Monitor kernel crash logs for md bitmap related oops until patches are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: md/md-llbitmap: prevent create failure bitmap UAF llbitmap_create() publishes mddev->bitmap before reading the bitmap superblock. This is needed because llbitmap_read_sb() can initialize a new bitmap and flush it through helpers that use mddev->bitmap. If llbitmap_read_sb() fails, the old cleanup dropped bitmap_info.mutex and freed llbitmap before clearing mddev->bitmap. Readers such as /proc/mdstat rely on bitmap_info.mutex to keep the bitmap pointer stable while collecting bitmap stats, so they could observe the stale pointer after the failed create path released the mutex. Clear mddev->bitmap while still holding bitmap_info.mutex, then free the failed llbitmap after dropping the mutex. This makes mutex-protected readers see either a live bitmap or no bitmap.

Affected packages

Ecosystem Package Introduced Fixed