CVE-2024-39476

CVE Details

Release Date:

2024-07-05

Description

In the Linux kernel, the following vulnerability has been resolved:\nmd/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING\nXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with\nsmall possibility, the root cause is exactly the same as commit\nbed9e27baf52 ('Revert 'md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d'')\nHowever, Dan reported another hang after that, and junxiao investigated\nthe problem and found out that this is caused by plugged bio can't issue\nfrom raid5d().\nCurrent implementation in raid5d() has a weird dependence:\n1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear\nMD_SB_CHANGE_PENDING;\n2) raid5d() handles IO in a deadloop, until all IO are issued;\n3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;\nThis behaviour is introduce before v2.6, and for consequence, if other\ncontext hold 'reconfig_mutex', and md_check_recovery() can't update\nsuper_block, then raid5d() will waste one cpu 100% by the deadloop, until\n'reconfig_mutex' is released.\nRefer to the implementation from raid1 and raid10, fix this problem by\nskipping issue IO if MD_SB_CHANGE_PENDING is still set after\nmd_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'\nis released. Meanwhile, the hang problem will be fixed as well.

See more information about CVE-2024-39476 from MITRE CVE dictionary and NIST NVD

CVSS Scoring

NOTE: The following CVSS v3.1 metrics and score provided are preliminary and subject to review.

Base Score:	5.5	CVSS Vector:	CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector:	Local network	Attack Complexity:	Low
Privileges Required:	Low	User Interaction:	None
Scope:	Unchanged	Confidentiality Impact:	None
Integrity Impact:	None	Availability Impact:	High

Errata information

Platform	Errata	Release Date
Oracle Linux version 8 (kernel)	ELSA-2024-5101	2024-08-08
Oracle Linux version 9 (kernel)	ELSA-2024-5928	2024-08-28