VYPR
Unrated severityNVD Advisory· Published Dec 9, 2025· Updated Apr 15, 2026

CVE-2023-53832

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

2
  • Linux/Kernelinferred2 versions
    (expand)+ 1 more
    • (no CPE)
    • (no CPE)

Patches

8

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

8

News mentions

0

No linked articles in our index yet.