Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

redhat логотип

CVE-2023-53832

Опубликовано: 09 дек. 2025
Источник: redhat
CVSS3: 4.7
EPSS Низкий

Описание

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
  1. 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")

    A null pointer dereference flaw was found in the Linux kernel's RAID10 implementation. When recovery is skipped on a clean array, init_resync() is called but close_sync() is not, leaving conf->have_replacement incorrectly set to 0. If a replacement device is later added and recovery is triggered, repl_bio is not allocated, causing a null pointer dereference when accessed.

Отчет

Exploitation requires specific RAID10 array operations including adding replacement devices after skipped recovery cycles. This represents a reliability issue for systems using RAID10 with device replacement workflows.

Затронутые пакеты

ПлатформаПакетСостояниеРекомендацияРелиз
Red Hat Enterprise Linux 10kernelNot affected
Red Hat Enterprise Linux 6kernelOut of support scope
Red Hat Enterprise Linux 7kernelFix deferred
Red Hat Enterprise Linux 7kernel-rtFix deferred
Red Hat Enterprise Linux 8kernel-rtFix deferred
Red Hat Enterprise Linux 9kernelFix deferred
Red Hat Enterprise Linux 9kernel-rtFix deferred
Red Hat Enterprise Linux 8kernelFixedRHSA-2023:707714.11.2023
Red Hat Enterprise Linux 8.8 Extended Update SupportkernelFixedRHSA-2023:753928.11.2023

Показывать по

Дополнительная информация

Статус:

Moderate
Дефект:
CWE-908
https://bugzilla.redhat.com/show_bug.cgi?id=2420309kernel: md/raid10: fix null-ptr-deref in raid10_sync_request

EPSS

Процентиль: 14%
0.0023
Низкий

4.7 Medium

CVSS3

Связанные уязвимости

ubuntu
8 месяцев назад

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/...

nvd
8 месяцев назад

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 skipp

debian
8 месяцев назад

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

github
8 месяцев назад

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 sk...

CVSS3: 7
fstec
больше 3 лет назад

Уязвимость функции raid10_sync_request() модуля drivers/md/raid10.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

EPSS

Процентиль: 14%
0.0023
Низкий

4.7 Medium

CVSS3