https://vulnerability.circl.lu/rss/recent/all/10 Most recent entries from all 2026-09-29T07:26:50.926251+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent entries. https://vulnerability.circl.lu/vuln/bell-cve-2026-90275 BELL-CVE-2026-90275 2026-09-29T07:26:50.983823+00:00

Affected: Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

 https://vulnerability.circl.lu/vuln/fkie_cve-2026-90275 fkie_cve-2026-90275 2026-09-29T07:26:50.983924+00:00

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.

 https://vulnerability.circl.lu/vuln/ghsa-c82r-j325-qwcg GHSA-c82r-j325-qwcg 2026-09-29T07:26:50.984005+00:00

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.

 https://vulnerability.circl.lu/vuln/opensuse-su-2026:11880-1 openSUSE-SU-2026:11880-1 — kernel-devel-7.2.7-1.1 on GA media 2026-09-29T07:26:50.984056+00:00

kernel-devel-7.2.7-1.1 on GA media

 https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-90275 UBUNTU-CVE-2026-90275 2026-09-29T07:26:50.984585+00:00

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 154 more

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.