In the Linux kernel, the following vulnerability has been resolved: md: wait for behind writes before destroying bitmap __md_stop() destroyed the bitmap before calling mddev_detach(). That made mddev_detach() skip bitmap_ops->wait_behind_writes(), because the bitmap was already disconnected from mddev. This was still safe for the legacy bitmap because bitmap_destroy() waits for behind writes itself. llbitmap keeps that wait in its ->wait_behind_writes() operation instead, while ->destroy() tears down the llbitmap storage. With the old ordering, RAID1 behind-write completions could still run after llbitmap storage had been freed. Call mddev_detach() before md_bitmap_destroy() so the common detach path can wait for behind writes while the bitmap is still alive. Only destroy the bitmap after those users are gone.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: md: wait for behind writes before
    destroying bitmap __md_stop() destroyed the bitmap before calling mddev_detach(). That made mddev_detach()
    skip bitmap_ops->wait_behind_writes(), because the bitmap was already disconnected from mddev. This was
    still safe for the legacy bitmap because bitmap_destroy() waits for behind writes itself. llbitmap keeps
    that wait in its ->wait_behind_writes() operation instead, while ->destroy() tears down the llbitmap
    storage. With the old ordering, RAID1 behind-write completions could still run after llbitmap storage had
    been freed. Call mddev_detach() before md_bitmap_destroy() so the common detach path can wait for behind
    writes while the bitmap is still alive. Only destroy the bitmap after those users are gone.
    (CVE-2026-90278)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - md: wait for behind writes before destroying bitmap __md_stop() destroyed the bitmap before calling     mddev_detach(). That made mddev_detach() skip bitmap_ops->wait_behind_writes(), because the bitmap was     already disconnected from mddev. This was still safe for the legacy bitmap because bitmap_destroy() waits     for behind writes itself. llbitmap keeps that wait in its ->wait_behind_writes() operation instead, while
    ->destroy() tears down the llbitmap storage. With the old ordering, RAID1 behind-write completions could     still run after llbitmap storage had been freed. Call mddev_detach() before md_bitmap_destroy() so the     common detach path can wait for behind writes while the bitmap is still alive. Only destroy the bitmap     after those users are gone. (CVE-2026-90278)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
475616	Google: sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_18: security update to 20198.0.0	Tenable Cloud Security	Google COS Security Checks	Local	high
475616	Google: sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_18: security update to 20198.0.0	Tenable Self-Hosted Container Security	Google COS Security Checks	Local	high
365258	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-3192)	Nessus	Amazon Linux Local Security Checks	Local	medium
347405	Linux Distros Unpatched Vulnerability : CVE-2026-90278	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-90278

high

Tenable Plugins

high

high

medium

high