CVE-2024-39476
published 2024-07-05CVE-2024-39476: In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING Xiao…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.18%
7.5th percentile
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
small possibility, the root cause is exactly the same as commit
bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
However, Dan reported another hang after that, and junxiao investigated
the problem and found out that this is caused by plugged bio can't issue
from raid5d().
Current implementation in raid5d() has a weird dependence:
1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadloop, until all IO are issued;
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;
This behaviour is introduce before v2.6, and for consequence, if other
context hold 'reconfig_mutex', and md_check_recovery() can't update
super_block, then raid5d() will waste one cpu 100% by the deadloop, until
'reconfig_mutex' is released.
Refer to the implementation from raid1 and raid10, fix this problem by
skipping issue IO if MD_SB_CHANGE_PENDING is still set after
md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'
is released. Meanwhile, the hang problem will be fixed as well.
Affected
39 ranges· showing 25
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.94-1 (bookworm) | linux 6.1.94-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | >= 1c00bb624cd084e2006520ad0edacaff0fb941c4 < 634ba3c97ec413cb10681c7b196db43ee461ecf4 | 634ba3c97ec413cb10681c7b196db43ee461ecf4 |
| linux | linux | >= 4.14.296 < 4.15 | 4.15 |
| linux | linux | >= 4.19.262 < 4.19.316 | 4.19.316 |
| linux | linux | >= 5.10.150 < 5.10.219 | 5.10.219 |
| linux | linux | >= 5.15.75 < 5.15.161 | 5.15.161 |
| linux | linux | >= 5.19.17 < 5.20 | 5.20 |
| linux | linux | >= 5.4.220 < 5.4.278 | 5.4.278 |
| linux | linux | >= 5e2cf333b7bd5d3e62595a44d598a254c697cd74 < 3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b | 3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b |
| linux | linux | >= 5e2cf333b7bd5d3e62595a44d598a254c697cd74 < cd2538e5af495b3c747e503db346470fc1ffc447 | cd2538e5af495b3c747e503db346470fc1ffc447 |
| linux | linux | >= 5e2cf333b7bd5d3e62595a44d598a254c697cd74 < e332a12f65d8fed8cf63bedb4e9317bb872b9ac7 | e332a12f65d8fed8cf63bedb4e9317bb872b9ac7 |
| linux | linux | >= 5e2cf333b7bd5d3e62595a44d598a254c697cd74 < 151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa | 151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa |
| linux | linux | >= 6.0.3 < 6.1 | 6.1 |
| linux | linux | >= 782b3e71c957991ac8ae53318bc369049d49bb53 < aa64464c8f4d2ab92f6d0b959a1e0767b829d787 | aa64464c8f4d2ab92f6d0b959a1e0767b829d787 |
| linux | linux | >= 9e86dffd0b02594d2e7c60c6db9e889c0395414b < 098d54934814dd876963abfe751c3b1cf7fbe56a | 098d54934814dd876963abfe751c3b1cf7fbe56a |
| linux | linux | >= f3d55bd5b7b928ad82f8075d89c908702f3593ab < b32aa95843cac6b12c2c014d40fca18aef24a347 | b32aa95843cac6b12c2c014d40fca18aef24a347 |
| linux | linux_kernel | >= 0 < 5.10.221-1 | 5.10.221-1 |
| linux | linux_kernel | >= 0 < 6.1.94-1 | 6.1.94-1 |
| linux | linux_kernel | >= 0 < 6.9.7-1 | 6.9.7-1 |
| linux | linux_kernel | >= 0 < 6.9.7-1 | 6.9.7-1 |
| linux | linux_kernel | >= 4.19 < 4.19.316 | 4.19.316 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_msrc5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
CISA ICS
Siemens SINEC OS
cisa_ics·2025-08-14
Siemens SINEC OS
ICS Advisory
##
Siemens SINEC OS
Release DateAugust 14, 2025
Alert CodeICSA-25-226-15
Related topics:
Industrial Control System Vulnerabilities, Industrial Control Systems
As of January 10, 2023, CISA will no longer be updating ICS security advisories for Siemens product vulnerabilities beyond the initial advisory. For the most up-to-date information on vulnerabilities in this advisory, please see Siemens' ProductCERT Security Advisories (CERT Services | Services | Siemens Global).
View CSAF
## 1. EXECUTIVE SUMMARY
- CVSS v3.1 9.1
- ATTENTION: Exploitable remotely/low attack complexity
- Vendor: Siemens
- Equipment: RUGGEDCOM, SCALANCE
- Vulnerabilities: NULL Pointer Dereference, Use After Free, Unchecked Input for Loop Condition, Out-of-bounds Write, Ou
Microsoft
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
vendor_msrc·2024-07-09·CVSS 5.5
CVE-2024-39476 [MEDIUM] CWE-667 md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
FAQ: Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by this vulnerability?
One of the main benefits to our customers who choose to use the Azure Linux distro is the commitment to keep it up to date with the most recent and most secure versions of the open source libraries with which the distro is composed. Microsoft is committed to transparency in this work which is why we began publishing CSAF/VEX in October 2025. See this blog post for more information. If impact to additional products is identified, we will update the CVE to reflect this.
Mariner: Mariner
Linux: Linux
Customer Action Required: Yes
Remediation: CBL-Mariner Release
Red Hat
kernel: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
vendor_redhat·2024-07-05·CVSS 5.5
CVE-2024-39476 [MEDIUM] CWE-833 kernel: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
kernel: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
small possibility, the root cause is exactly the same as commit
bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
However, Dan reported another hang after that, and junxiao investigated
the problem and found out that this is caused by plugged bio can't issue
from raid5d().
Current implementation in raid5d() has a weird dependence:
1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadl
Debian
CVE-2024-39476: linux - In the Linux kernel, the following vulnerability has been resolved: md/raid5: f...
vendor_debian·2024·CVSS 5.5
CVE-2024-39476 [MEDIUM] CVE-2024-39476: linux - In the Linux kernel, the following vulnerability has been resolved: md/raid5: f...
In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"") However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d(). Current implementation in raid5d() has a weird dependence: 1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be c
GHSA
GHSA-wx95-q6gv-qpp4: In the Linux kernel, the following vulnerability has been resolved:
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDIN
ghsa_unreviewed·2024-07-05
CVE-2024-39476 [MEDIUM] CWE-667 GHSA-wx95-q6gv-qpp4: In the Linux kernel, the following vulnerability has been resolved:
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDIN
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
small possibility, the root cause is exactly the same as commit
bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
However, Dan reported another hang after that, and junxiao investigated
the problem and found out that this is caused by plugged bio can't issue
from raid5d().
Current implementation in raid5d() has a weird dependence:
1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadloop, until all IO are issued;
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to
OSV
CVE-2024-39476: In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
osv·2024-07-05·CVSS 5.5
CVE-2024-39476 [MEDIUM] CVE-2024-39476: In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"") However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d(). Current implementation in raid5d() has a weird dependence: 1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be c
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56ahttps://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fahttps://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024bhttps://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56ahttps://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fahttps://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024bhttps://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7
2024-07-05
Published