Skip to main content

Linux CVE-2026-43271

| EUVDEUVD-2026-27666 MEDIUM
NULL Pointer Dereference (CWE-476)
2026-05-06 Linux GHSA-3r8g-c43c-9gw2
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
MEDIUM
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

3
CVSS changed
May 08, 2026 - 20:07 NVD
5.5 (MEDIUM)
Patch available
May 06, 2026 - 13:32 EUVD
CVE Published
May 06, 2026 - 11:28 nvd
MEDIUM 5.5

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

md-cluster: fix NULL pointer dereference in process_metadata_update

The function process_metadata_update() blindly dereferences the 'thread' pointer (acquired via rcu_dereference_protected) within the wait_event() macro.

While the code comment states "daemon thread must exist", there is a valid race condition window during the MD array startup sequence (md_run):

  1. bitmap_load() is called, which invokes md_cluster_ops->join().
  2. join() starts the "cluster_recv" thread (recv_daemon).
  3. At this point, recv_daemon is active and processing messages.
  4. However, mddev->thread (the main MD thread) is not initialized until

later in md_run().

If a METADATA_UPDATED message is received from a remote node during this specific window, process_metadata_update() will be called while mddev->thread is still NULL, leading to a kernel panic.

To fix this, we must validate the 'thread' pointer. If it is NULL, we release the held lock (no_new_dev_lockres) and return early, safely ignoring the update request as the array is not yet fully ready to process it.

Analysis

In the Linux kernel, the following vulnerability has been resolved:

md-cluster: fix NULL pointer dereference in process_metadata_update

The function process_metadata_update() blindly dereferences the 'thread' pointer (acquired via rcu_dereference_protected) within the wait_event() macro.

While the code comment states "daemon thread must exist", there is a valid race condition window during the MD array startup sequence (md_run):

  1. bitmap_load() is called, which invokes md_cluster_ops->join().
  2. join() starts the "cluster_recv" thread (recv_daemon).
  3. At this point, recv_daemon is active and processing messages.
  4. However, mddev->thread (the main MD thread) is not initialized until

later in md_run().

If a METADATA_UPDATED message is received from a remote node during this specific window, process_metadata_update() will be called while mddev->thread is still NULL, leading to a kernel panic.

To fix this, we must validate the 'thread' pointer. If it is NULL, we release the held lock (no_new_dev_lockres) and return early, safely ignoring the update request as the array is not yet fully ready to process it.

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

CVE-2026-43271 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy