CVE-2024-39476

一、漏洞信息
漏洞编号：CVE-2024-39476
漏洞归属组件：kernel
漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.0,6.1.14,6.1.19,6.1.5,6.1.6,6.1.8,6.4.0,6.6.0
CVSS V3.0分值：
BaseScore：5.5 Medium
Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
漏洞简述：
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.
漏洞公开时间：2024-07-05 15:15:10
漏洞创建时间：2024-07-05 21:03:21
漏洞详情参考链接：
https://nvd.nist.gov/vuln/detail/CVE-2024-39476

更多参考(点击展开)

参考来源	参考链接	来源链接
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7
suse_bugzilla	http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-39476	https://bugzilla.suse.com/show_bug.cgi?id=1227437
suse_bugzilla	https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-39476.mbox	https://bugzilla.suse.com/show_bug.cgi?id=1227437
suse_bugzilla	https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347	https://bugzilla.suse.com/show_bug.cgi?id=1227437
suse_bugzilla	https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4	https://bugzilla.suse.com/show_bug.cgi?id=1227437
suse_bugzilla	https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787	https://bugzilla.suse.com/show_bug.cgi?id=1227437
suse_bugzilla	https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a	https://bugzilla.suse.com/show_bug.cgi?id=1227437
suse_bugzilla	https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b	https://bugzilla.suse.com/show_bug.cgi?id=1227437
suse_bugzilla	https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447	https://bugzilla.suse.com/show_bug.cgi?id=1227437
suse_bugzilla	https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7	https://bugzilla.suse.com/show_bug.cgi?id=1227437
suse_bugzilla	https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa	https://bugzilla.suse.com/show_bug.cgi?id=1227437
suse_bugzilla	https://www.cve.org/CVERecord?id=CVE-2024-39476	https://bugzilla.suse.com/show_bug.cgi?id=1227437
redhat_bugzilla	https://access.redhat.com/errata/RHSA-2024:5102	https://bugzilla.redhat.com/show_bug.cgi?id=2295914
redhat_bugzilla	https://access.redhat.com/errata/RHSA-2024:5101	https://bugzilla.redhat.com/show_bug.cgi?id=2295914
ubuntu	https://www.cve.org/CVERecord?id=CVE-2024-39476	https://ubuntu.com/security/CVE-2024-39476
ubuntu	https://git.kernel.org/linus/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa (6.10-rc1)	https://ubuntu.com/security/CVE-2024-39476
ubuntu	https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347	https://ubuntu.com/security/CVE-2024-39476
ubuntu	https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4	https://ubuntu.com/security/CVE-2024-39476
ubuntu	https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787	https://ubuntu.com/security/CVE-2024-39476
ubuntu	https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a	https://ubuntu.com/security/CVE-2024-39476
ubuntu	https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b	https://ubuntu.com/security/CVE-2024-39476
ubuntu	https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447	https://ubuntu.com/security/CVE-2024-39476
ubuntu	https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7	https://ubuntu.com/security/CVE-2024-39476
ubuntu	https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa	https://ubuntu.com/security/CVE-2024-39476
ubuntu	https://nvd.nist.gov/vuln/detail/CVE-2024-39476	https://ubuntu.com/security/CVE-2024-39476
ubuntu	https://launchpad.net/bugs/cve/CVE-2024-39476	https://ubuntu.com/security/CVE-2024-39476
ubuntu	https://security-tracker.debian.org/tracker/CVE-2024-39476	https://ubuntu.com/security/CVE-2024-39476
debian		https://security-tracker.debian.org/tracker/CVE-2024-39476
anolis		https://anas.openanolis.cn/cves/detail/CVE-2024-39476
cve_search		https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347
cve_search		https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4
cve_search		https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787
cve_search		https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a
cve_search		https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b
cve_search		https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447
cve_search		https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7
cve_search		https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa
mageia		http://advisories.mageia.org/MGASA-2024-0263.html

漏洞分析指导链接：
https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
漏洞数据来源:
openBrain开源漏洞感知系统
漏洞补丁信息：

详情(点击展开)

影响的包	修复补丁	问题引入补丁	来源
	https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a		nvd
	https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa		nvd
	https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b		nvd
	https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4		nvd
	https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787		nvd
	https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347		nvd
	https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447		nvd
	https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7		nvd
linux	https://git.kernel.org/linus/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa	https://git.kernel.org/linus/5e2cf333b7bd5d3e62595a44d598a254c697cd74	ubuntu

二、漏洞分析结构反馈
影响性分析说明：
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.
openEuler评分：
5.5
Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
受影响版本排查(受影响/不受影响)：
1.openEuler-22.03-LTS-SP3(5.10.0):受影响
2.openEuler-22.03-LTS-SP4(5.10.0):受影响
3.openEuler-24.03-LTS(6.6.0):受影响
4.openEuler-20.03-LTS-SP4(4.19.90):不受影响
5.openEuler-22.03-LTS-SP1(5.10.0):不受影响
6.master(6.1.0):不受影响
7.openEuler-24.03-LTS-Next(6.6.0):不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4(4.19.90):否
2.openEuler-22.03-LTS-SP1(5.10.0):否
3.openEuler-22.03-LTS-SP3(5.10.0):否
4.master(6.1.0):否
5.openEuler-24.03-LTS(6.6.0):否
6.openEuler-24.03-LTS-Next(6.6.0):否
7.openEuler-22.03-LTS-SP4(5.10.0):否

三、漏洞修复
安全公告链接：https://www.openeuler.org/zh/security/safety-bulletin/detail/?id=openEuler-SA-2024-2076

Hi openeuler-ci-bot, welcome to the openEuler Community.
I'm the Bot here serving you. You can find the instructions on how to interact with me at Here.
If you have any questions, please contact the SIG: Kernel, and any of the maintainers.

@yangyingliang ,@jiaoff ,@guohaocs2c ,@hanjun-guo ,@woqidaideshi ,@newbeats ,@zhangyi089 ,@colyli ,@thundertown ,@htforge ,@chiqijun ,@lengchao ,@zhujianwei001 ,@kylin-mayukun ,@wangxiongfeng ,@wkfxxx ,@SuperSix173 ,@jentlestea ,@oskernel0719 ,@gasonchen 
**issue处理注意事项:** 
**1. 当前issue受影响的分支提交pr时, 须在pr描述中填写当前issue编号进行关联, 否则无法关闭当前issue;**
**2. 模板内容需要填写完整, 无论是受影响或者不受影响都需要填写完整内容,未引入的分支不需要填写, 否则无法关闭当前issue;**
**3. 以下为模板中需要填写完整的内容, 请复制到评论区回复, 注: 内容的标题名称(影响性分析说明, openEuler评分, 受影响版本排查(受影响/不受影响), 修复是否涉及abi变化(是/否))不能省略,省略后cve-manager将无法正常解析填写内容.**
************************************************************************
影响性分析说明:

openEuler评分: (评分和向量)

受影响版本排查(受影响/不受影响): 
1.master(6.1.0):
2.openEuler-20.03-LTS-SP4(4.19.90):
3.openEuler-22.03-LTS-SP1(5.10.0):
4.openEuler-22.03-LTS-SP3(5.10.0):
5.openEuler-22.03-LTS-SP4(5.10.0):
6.openEuler-24.03-LTS(6.6.0):
7.openEuler-24.03-LTS-Next(6.6.0):

修复是否涉及abi变化(是/否)：
1.master(6.1.0):
2.openEuler-20.03-LTS-SP4(4.19.90):
3.openEuler-22.03-LTS-SP1(5.10.0):
4.openEuler-22.03-LTS-SP3(5.10.0):
5.openEuler-22.03-LTS-SP4(5.10.0):
6.openEuler-24.03-LTS(6.6.0):
7.openEuler-24.03-LTS-Next(6.6.0):

-----------------------------------------------------------------------
issue处理具体操作请参考: 
https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
pr关联issue具体操作请参考:
https://gitee.com/help/articles/4142

参考网址	关联pr	状态	补丁链接
https://nvd.nist.gov/vuln/detail/CVE-2024-39476	None	None	https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447 https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787 https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347 https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7 https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4 https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b
https://ubuntu.com/security/CVE-2024-39476
https://www.opencve.io/cve/CVE-2024-39476	None	None	https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447 https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787 https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347 https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7 https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4 https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2024-39476
https://security-tracker.debian.org/tracker/CVE-2024-39476

说明：补丁链接仅供初步排查参考，实际可用性请人工再次确认，补丁下载验证可使用CVE补丁工具。
若补丁不准确，烦请在此issue下评论 '/report-patch 参考网址补丁链接1,补丁链接2' 反馈正确信息，便于我们不断优化工具，不胜感激。
如 /report-patch https://security-tracker.debian.org/tracker/CVE-2021-3997 https://github.com/systemd/systemd/commit/5b1cf7a9be37e20133c0208005274ce4a5b5c6a1

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

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:

md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
raid5d() handles IO in a deadloop, until all IO are issued;
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.

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:不受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否

===========================================================

@ 经过 cve-manager 解析, 已分析的内容如下表所示:

状态	需分析	内容
已分析	1.影响性分析说明	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.
已分析	2.openEulerScore	5.5
已分析	3.openEulerVector	AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
已分析	4.受影响版本排查	openEuler-22.03-LTS-SP1:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-24.03-LTS:受影响,openEuler-20.03-LTS-SP4:不受影响,openEuler-22.03-LTS-SP4:不受影响,master:不受影响,openEuler-24.03-LTS-Next:不受影响
已分析	5.修复是否涉及abi变化	openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP1:否,openEuler-22.03-LTS-SP3:否,master:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-22.03-LTS-SP4:否

请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.

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

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:

md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
raid5d() handles IO in a deadloop, until all IO are issued;
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.

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:不受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否

===========================================================

@ 经过 cve-manager 解析, 已分析的内容如下表所示:

状态	需分析	内容
已分析	1.影响性分析说明	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.
已分析	2.openEulerScore	5.5
已分析	3.openEulerVector	AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
已分析	4.受影响版本排查	openEuler-22.03-LTS-SP1:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-24.03-LTS:受影响,openEuler-20.03-LTS-SP4:不受影响,openEuler-22.03-LTS-SP4:不受影响,master:不受影响,openEuler-24.03-LTS-Next:不受影响
已分析	5.修复是否涉及abi变化	openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP1:否,openEuler-22.03-LTS-SP3:否,master:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-22.03-LTS-SP4:否

请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.

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

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:

md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
raid5d() handles IO in a deadloop, until all IO are issued;
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.

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:不受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否

===========================================================

@ 经过 cve-manager 解析, 已分析的内容如下表所示:

状态	需分析	内容
已分析	1.影响性分析说明	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.
已分析	2.openEulerScore	5.5
已分析	3.openEulerVector	AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
已分析	4.受影响版本排查	openEuler-22.03-LTS-SP1:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-24.03-LTS:受影响,openEuler-20.03-LTS-SP4:不受影响,openEuler-22.03-LTS-SP4:不受影响,master:不受影响,openEuler-24.03-LTS-Next:不受影响
已分析	5.修复是否涉及abi变化	openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP1:否,openEuler-22.03-LTS-SP3:否,master:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-22.03-LTS-SP4:否

请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.

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

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:

md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
raid5d() handles IO in a deadloop, until all IO are issued;
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.

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否

===========================================================

@ 经过 cve-manager 解析, 已分析的内容如下表所示:

状态	需分析	内容
已分析	1.影响性分析说明	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.
已分析	2.openEulerScore	5.5
已分析	3.openEulerVector	AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
已分析	4.受影响版本排查	openEuler-22.03-LTS-SP1:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS:受影响,openEuler-20.03-LTS-SP4:不受影响,master:不受影响,openEuler-24.03-LTS-Next:不受影响
已分析	5.修复是否涉及abi变化	openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP1:否,openEuler-22.03-LTS-SP3:否,master:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-22.03-LTS-SP4:否

请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.

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

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:

md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
raid5d() handles IO in a deadloop, until all IO are issued;
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.

The Linux kernel CVE team has assigned CVE-2024-39476 to this issue.

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否

@ 经过 cve-manager 解析, 已分析的内容如下表所示:

状态	需分析	内容
已分析	1.影响性分析说明	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.The Linux kernel CVE team has assigned CVE-2024-39476 to this issue.
已分析	2.openEulerScore	5.5
已分析	3.openEulerVector	AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
已分析	4.受影响版本排查	openEuler-22.03-LTS-SP1:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS:受影响,openEuler-20.03-LTS-SP4:不受影响,master:不受影响,openEuler-24.03-LTS-Next:不受影响
已分析	5.修复是否涉及abi变化	openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP1:否,openEuler-22.03-LTS-SP3:否,master:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-22.03-LTS-SP4:否

请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.

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

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:

md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
raid5d() handles IO in a deadloop, until all IO are issued;
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.

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:不受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否

===========================================================

@ 经过 cve-manager 解析, 已分析的内容如下表所示:

状态	需分析	内容
已分析	1.影响性分析说明	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.
已分析	2.openEulerScore	5.5
已分析	3.openEulerVector	AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
已分析	4.受影响版本排查	openEuler-22.03-LTS-SP3:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS:受影响,openEuler-20.03-LTS-SP4:不受影响,openEuler-22.03-LTS-SP1:不受影响,master:不受影响,openEuler-24.03-LTS-Next:不受影响
已分析	5.修复是否涉及abi变化	openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP1:否,openEuler-22.03-LTS-SP3:否,master:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-22.03-LTS-SP4:否

请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.

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

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:

md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
raid5d() handles IO in a deadloop, until all IO are issued;
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.

The Linux kernel CVE team has assigned CVE-2024-39476 to this issue.

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否

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

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:

md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
raid5d() handles IO in a deadloop, until all IO are issued;
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.

The Linux kernel CVE team has assigned CVE-2024-39476 to this issue.

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否

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

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:

md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
raid5d() handles IO in a deadloop, until all IO are issued;
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.

The Linux kernel CVE team has assigned CVE-2024-39476 to this issue.

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否

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

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:

md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
raid5d() handles IO in a deadloop, until all IO are issued;
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.

The Linux kernel CVE team has assigned CVE-2024-39476 to this issue.

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否

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

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:

md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
raid5d() handles IO in a deadloop, until all IO are issued;
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.

The Linux kernel CVE team has assigned CVE-2024-39476 to this issue.

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否

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

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:

md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
MD_SB_CHANGE_PENDING;
raid5d() handles IO in a deadloop, until all IO are issued;
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.

The Linux kernel CVE team has assigned CVE-2024-39476 to this issue.

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否

src-openEuler/kernel

内容风险标识

评论 (25)

src-openEuler/kernel .gitee-modal { width: 500px !important; }

内容风险标识

CVE-2024-39476

评论 (25)

搜索帮助

src-openEuler/kernel