CVE-2023-53832
Description
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: fix null-ptr-deref in raid10_sync_request
init_resync() inits mempool and sets conf->have_replacemnt at the beginning of sync, close_sync() frees the mempool when sync is completed.
After [1] recovery might be skipped and init_resync() is called but close_sync() is not. null-ptr-deref occurs with r10bio->dev[i].repl_bio.
The following is one way to reproduce the issue.
1) create a array, wait for resync to complete, mddev->recovery_cp is set to MaxSector. 2) recovery is woken and it is skipped. conf->have_replacement is set to 0 in init_resync(). close_sync() not called. 3) some io errors and rdev A is set to WantReplacement. 4) a new device is added and set to A's replacement. 5) recovery is woken, A have replacement, but conf->have_replacemnt is 0. r10bio->dev[i].repl_bio will not be alloced and null-ptr-deref occurs.
Fix it by not calling init_resync() if recovery skipped.
[1] commit 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled")
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A null-pointer dereference in Linux kernel's md/raid10 driver can be triggered when recovery is skipped, leading to a system crash.
Vulnerability
Overview
CVE-2023-53832 is a null-pointer dereference vulnerability in the Linux kernel's md/raid10 driver, specifically in the raid10_sync_request function. The root cause is an asymmetry in the synchronization lifecycle: init_resync() initializes a memory pool and sets conf->have_replacement, while close_sync() frees that pool. When recovery is skipped due to commit [1] (7e83ccbecd60), init_resync() is called but close_sync() is not, leaving the pool uninitialized for subsequent operations.
Exploitation
Conditions
To trigger the bug, an attacker must be able to perform a specific sequence of operations on a RAID10 array: create the array and let resync complete, then cause I/O errors to mark a device as WantReplacement, add a replacement device, and finally trigger recovery. Under these conditions, conf->have_replacement remains 0, so r10bio->dev[i].repl_bio is never allocated, leading to a null-pointer dereference when the sync code attempts to use it.
Impact
A successful exploit results in a denial of service (kernel panic) due to the null-pointer dereference. No privilege escalation or data corruption is described in the advisory, but the crash can render the system unavailable.
Mitigation
The fix, implemented in commits [2] and [3], ensures that init_resync() is not called when recovery is skipped, preventing the mismatch. Users should apply the latest stable kernel updates that include these patches.
AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
838d33593260514964127be77bdbf104b1c9168695084077eb50fd1c3d9d099b503e4edc59e9efc77efd1a405c6f02295Vulnerability mechanics
Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
8- git.kernel.org/stable/c/14964127be77884003976a392c9faa9ebaabbbe1nvd
- git.kernel.org/stable/c/38d33593260536840b49fd1dcac9aedfd14a9d42nvd
- git.kernel.org/stable/c/68695084077e3de9d3e94e09238ace2b6f246446nvd
- git.kernel.org/stable/c/99b503e4edc5938885d839cf0e7571963f75d800nvd
- git.kernel.org/stable/c/9e9efc77efd1956cc244af975240f2513d78a371nvd
- git.kernel.org/stable/c/a405c6f0229526160aa3f177f65e20c86fce84c5nvd
- git.kernel.org/stable/c/b50fd1c3d9d0175aa29ff2706ef36cc178bc356anvd
- git.kernel.org/stable/c/bdbf104b1c91fbf38f82c522ebf75429f094292anvd
News mentions
0No linked articles in our index yet.