Описание
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):
- bitmap_load() is called, which invokes md_cluster_ops->join().
- join() starts the "cluster_recv" thread (recv_daemon).
- At this point, recv_daemon is active and processing messages.
- 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 ...
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):
- bitmap_load() is called, which invokes md_cluster_ops->join().
- join() starts the "cluster_recv" thread (recv_daemon).
- At this point, recv_daemon is active and processing messages.
- 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.
Ссылки
- https://nvd.nist.gov/vuln/detail/CVE-2026-43271
- https://git.kernel.org/stable/c/721599e837d3f4c0e6cc14da059612c017b6d3ec
- https://git.kernel.org/stable/c/a61c1bc84c4a0f1e7c2fe55b0f43d7d94af4adf1
- https://git.kernel.org/stable/c/dceb5a843910004cb118148e267036104fc3ee43
- https://git.kernel.org/stable/c/dec123825c1ed74d98fd5fc7571a851dea4f46ff
- https://git.kernel.org/stable/c/f150e753cb8dd756085f46e86f2c35ce472e0a3c
Связанные уязвимости
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...
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...
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 hel
In the Linux kernel, the following vulnerability has been resolved: m ...
ELSA-2026-50372: Unbreakable Enterprise kernel security update (IMPORTANT)