gsd-2024-26758
Vulnerability from gsd
Modified
2024-02-20 06:02
Details
In the Linux kernel, the following vulnerability has been resolved:
md: Don't ignore suspended array in md_check_recovery()
mddev_suspend() never stop sync_thread, hence it doesn't make sense to
ignore suspended array in md_check_recovery(), which might cause
sync_thread can't be unregistered.
After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following
hang can be triggered by test shell/integrity-caching.sh:
1) suspend the array:
raid_postsuspend
mddev_suspend
2) stop the array:
raid_dtr
md_stop
__md_stop_writes
stop_sync_thread
set_bit(MD_RECOVERY_INTR, &mddev->recovery);
md_wakeup_thread_directly(mddev->sync_thread);
wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))
3) sync thread done:
md_do_sync
set_bit(MD_RECOVERY_DONE, &mddev->recovery);
md_wakeup_thread(mddev->thread);
4) daemon thread can't unregister sync thread:
md_check_recovery
if (mddev->suspended)
return; -> return directly
md_read_sync_thread
clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
-> MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang;
This problem is not just related to dm-raid, fix it by ignoring
suspended array in md_check_recovery(). And follow up patches will
improve dm-raid better to frozen sync thread during suspend.
Aliases
{
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2024-26758"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Don\u0027t ignore suspended array in md_check_recovery()\n\nmddev_suspend() never stop sync_thread, hence it doesn\u0027t make sense to\nignore suspended array in md_check_recovery(), which might cause\nsync_thread can\u0027t be unregistered.\n\nAfter commit f52f5c71f3d4 (\"md: fix stopping sync thread\"), following\nhang can be triggered by test shell/integrity-caching.sh:\n\n1) suspend the array:\nraid_postsuspend\n mddev_suspend\n\n2) stop the array:\nraid_dtr\n md_stop\n __md_stop_writes\n stop_sync_thread\n set_bit(MD_RECOVERY_INTR, \u0026mddev-\u003erecovery);\n md_wakeup_thread_directly(mddev-\u003esync_thread);\n wait_event(..., !test_bit(MD_RECOVERY_RUNNING, \u0026mddev-\u003erecovery))\n\n3) sync thread done:\nmd_do_sync\n set_bit(MD_RECOVERY_DONE, \u0026mddev-\u003erecovery);\n md_wakeup_thread(mddev-\u003ethread);\n\n4) daemon thread can\u0027t unregister sync thread:\nmd_check_recovery\n if (mddev-\u003esuspended)\n return; -\u003e return directly\n md_read_sync_thread\n clear_bit(MD_RECOVERY_RUNNING, \u0026mddev-\u003erecovery);\n -\u003e MD_RECOVERY_RUNNING can\u0027t be cleared, hence step 2 hang;\n\nThis problem is not just related to dm-raid, fix it by ignoring\nsuspended array in md_check_recovery(). And follow up patches will\nimprove dm-raid better to frozen sync thread during suspend.",
"id": "GSD-2024-26758",
"modified": "2024-02-20T06:02:29.301433Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cve@kernel.org",
"ID": "CVE-2024-26758",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Linux",
"version": {
"version_data": [
{
"version_affected": "\u003c",
"version_name": "68866e425be2",
"version_value": "a55f0d6179a1"
},
{
"version_value": "not down converted",
"x_cve_json_5_version_data": {
"defaultStatus": "affected",
"versions": [
{
"status": "affected",
"version": "3.0"
},
{
"lessThan": "3.0",
"status": "unaffected",
"version": "0",
"versionType": "custom"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.7",
"versionType": "custom"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.8",
"versionType": "original_commit_for_fix"
}
]
}
}
]
}
}
]
},
"vendor_name": "Linux"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Don\u0027t ignore suspended array in md_check_recovery()\n\nmddev_suspend() never stop sync_thread, hence it doesn\u0027t make sense to\nignore suspended array in md_check_recovery(), which might cause\nsync_thread can\u0027t be unregistered.\n\nAfter commit f52f5c71f3d4 (\"md: fix stopping sync thread\"), following\nhang can be triggered by test shell/integrity-caching.sh:\n\n1) suspend the array:\nraid_postsuspend\n mddev_suspend\n\n2) stop the array:\nraid_dtr\n md_stop\n __md_stop_writes\n stop_sync_thread\n set_bit(MD_RECOVERY_INTR, \u0026mddev-\u003erecovery);\n md_wakeup_thread_directly(mddev-\u003esync_thread);\n wait_event(..., !test_bit(MD_RECOVERY_RUNNING, \u0026mddev-\u003erecovery))\n\n3) sync thread done:\nmd_do_sync\n set_bit(MD_RECOVERY_DONE, \u0026mddev-\u003erecovery);\n md_wakeup_thread(mddev-\u003ethread);\n\n4) daemon thread can\u0027t unregister sync thread:\nmd_check_recovery\n if (mddev-\u003esuspended)\n return; -\u003e return directly\n md_read_sync_thread\n clear_bit(MD_RECOVERY_RUNNING, \u0026mddev-\u003erecovery);\n -\u003e MD_RECOVERY_RUNNING can\u0027t be cleared, hence step 2 hang;\n\nThis problem is not just related to dm-raid, fix it by ignoring\nsuspended array in md_check_recovery(). And follow up patches will\nimprove dm-raid better to frozen sync thread during suspend."
}
]
},
"generator": {
"engine": "bippy-5f0117140d9a"
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "n/a"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://git.kernel.org/stable/c/a55f0d6179a19c6b982e2dc344d58c98647a3be0",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/a55f0d6179a19c6b982e2dc344d58c98647a3be0"
},
{
"name": "https://git.kernel.org/stable/c/1baae052cccd08daf9a9d64c3f959d8cdb689757",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/1baae052cccd08daf9a9d64c3f959d8cdb689757"
}
]
}
},
"nvd.nist.gov": {
"cve": {
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Don\u0027t ignore suspended array in md_check_recovery()\n\nmddev_suspend() never stop sync_thread, hence it doesn\u0027t make sense to\nignore suspended array in md_check_recovery(), which might cause\nsync_thread can\u0027t be unregistered.\n\nAfter commit f52f5c71f3d4 (\"md: fix stopping sync thread\"), following\nhang can be triggered by test shell/integrity-caching.sh:\n\n1) suspend the array:\nraid_postsuspend\n mddev_suspend\n\n2) stop the array:\nraid_dtr\n md_stop\n __md_stop_writes\n stop_sync_thread\n set_bit(MD_RECOVERY_INTR, \u0026mddev-\u003erecovery);\n md_wakeup_thread_directly(mddev-\u003esync_thread);\n wait_event(..., !test_bit(MD_RECOVERY_RUNNING, \u0026mddev-\u003erecovery))\n\n3) sync thread done:\nmd_do_sync\n set_bit(MD_RECOVERY_DONE, \u0026mddev-\u003erecovery);\n md_wakeup_thread(mddev-\u003ethread);\n\n4) daemon thread can\u0027t unregister sync thread:\nmd_check_recovery\n if (mddev-\u003esuspended)\n return; -\u003e return directly\n md_read_sync_thread\n clear_bit(MD_RECOVERY_RUNNING, \u0026mddev-\u003erecovery);\n -\u003e MD_RECOVERY_RUNNING can\u0027t be cleared, hence step 2 hang;\n\nThis problem is not just related to dm-raid, fix it by ignoring\nsuspended array in md_check_recovery(). And follow up patches will\nimprove dm-raid better to frozen sync thread during suspend."
}
],
"id": "CVE-2024-26758",
"lastModified": "2024-04-03T17:24:18.150",
"metrics": {},
"published": "2024-04-03T17:15:52.263",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/1baae052cccd08daf9a9d64c3f959d8cdb689757"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a55f0d6179a19c6b982e2dc344d58c98647a3be0"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
}
}
}
Loading...