md/raid1: don't set array_frozen in raid1_takeover() (CVE-2026-90275) | HOL Guard CVE

Unknown severity · Source severity not reportedCVE-2026-90275

md/raid1: don't set array_frozen in raid1_takeover()

Answer in brief

CVE-2026-90275 records a Unknown severity vulnerability in md/raid1: don't set array_frozen in raid1_takeover(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Analysis pending evidence review

HOL Guard separates source facts from reviewed analysis. See the methodology.

Published Sep 17, 2026Updated Sep 17, 2026Source checked Sep 17, 2026First seen by HOL Sep 17, 2026Material review Sep 17, 2026

Upstream Advisory

Key facts

Risk: Unknown severitySource severity not reported
Exploitation: Not marked as known exploited
Affected software: 2 mapped packages or products
Fix availability: Available

Why this deserves its current priority

A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.

Analysis status

Analysis pending evidence review

Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.

Affected scope and exposure questions

The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Mapped affected packages and fixed versions
Package	Affected range	Fixed version
Linux/Linuxgeneric	>=b39f35ebe86d88788d85f61e83c81c308cb76727 <668d99ba47210ab6ceb18f1cf022c0accca7e3bb \|\| >=b39f35ebe86d88788d85f61e83c81c308cb76727 <c57ec2749ee03cace564eec7bb37c89dc3d8d47b \|\| >=b39f35ebe86d88788d85f61e83c81c308cb76727 <f9cdb5bb8efbf401e84d850828271af87e6be2dc \|\| >=b39f35ebe86d88788d85f61e83c81c308cb76727 <b6ec4bf1ec4446c0213c08ea493e48e6b83cd1af \|\| >=b39f35ebe86d88788d85f61e83c81c308cb76727 <dc386aa0ac0a3ec06c9a3ea9b064b073fb72a916	668d99ba47210ab6ceb18f1cf022c0accca7e3bb, c57ec2749ee03cace564eec7bb37c89dc3d8d47b, f9cdb5bb8efbf401e84d850828271af87e6be2dc, b6ec4bf1ec4446c0213c08ea493e48e6b83cd1af, dc386aa0ac0a3ec06c9a3ea9b064b073fb72a916
Linux/Linuxgeneric	6.6	Not reported

Recommended response

Check inventory. Check lockfiles and deployed manifests for Linux/Linux, Linux/Linux.
Review the reported fix. Update Linux/Linux to 668d99ba47210ab6ceb18f1cf022c0accca7e3bb if you use the affected versions. Test the change in a non-production environment first.

Evidence timeline and material changes

Published upstream
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:record
Source modified
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:record
First seen by HOL
Sep 17, 2026

Sources and claim methodology

Upstream source description

In the Linux kernel, the following vulnerability has been resolved: md/raid1: don't set array_frozen in raid1_takeover() raid1_takeover() sets conf->array_frozen = 1 on the newly-allocated r1conf and nothing ever clears it, so every I/O to the array stalls permanently once _wait_barrier() sees it stuck at 1. This used to be harmless: level_store() called mddev_resume() right after pers->run(), which called raid1_quiesce(mddev, 0) and cleared array_frozen back to 0 regardless of what raid1_takeover() set. Commit b39f35ebe86d ("md: don't quiesce in mddev_suspend()") removed that quiesce(mddev, 0) call, so the pre-set now sticks. setup_conf() already zero-initializes the new r1conf via kzalloc, so just don't set array_frozen here. Same class of bug as commit 892da88d1cd9 ("md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()"), also triggered by b39f35ebe86d.

Quoted source text, attributed separately from HOL analysis.