### [CVE-2024-39476](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-39476)
![](https://img.shields.io/static/v1?label=Product&message=Linux&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=1c00bb624cd084e2006520ad0edacaff0fb941c4%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=2cab058f2b147e0b7c01546ba00445e5701861f5%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=5e2cf333b7bd5d3e62595a44d598a254c697cd74%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=6.1%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=782b3e71c957991ac8ae53318bc369049d49bb53%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=7d808fe6af8409cf9f46ed2b10840e5788985e9b%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=91962e40ec3d26e291db230cd45b302da2aff200%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=9e86dffd0b02594d2e7c60c6db9e889c0395414b%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=f3d55bd5b7b928ad82f8075d89c908702f3593ab%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=blue)

### Description

In the Linux kernel, the following vulnerability has been resolved:md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDINGXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang withsmall possibility, the root cause is exactly the same as commitbed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")However, Dan reported another hang after that, and junxiao investigatedthe problem and found out that this is caused by plugged bio can't issuefrom 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 othercontext hold 'reconfig_mutex', and md_check_recovery() can't updatesuper_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 byskipping issue IO if MD_SB_CHANGE_PENDING is still set aftermd_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'is released. Meanwhile, the hang problem will be fixed as well.

### POC

#### Reference
No PoCs from references.

#### Github
- https://github.com/fkie-cad/nvd-json-data-feeds