Unrestricted Externally Accessible Lock Affecting kernel-modules-internal package, versions *


Severity

Recommended
low

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.17% (6th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL8-KERNELMODULESINTERNAL-21040961
  • published16 Oct 2026
  • disclosed17 Sept 2026

Introduced: 17 Sep 2026

NewCVE-2026-90275  (opens in a new tab)
CWE-412  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:8 kernel-modules-internal.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-modules-internal package and not the kernel-modules-internal package as distributed by RHEL. See How to fix? for RHEL:8 relevant fixed versions and status.

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.

CVSS Base Scores

version 3.1