FKIE_CVE-2024-26962
Vulnerability from fkie_nvd - Published: 2024-05-01 06:15 - Updated: 2026-06-17 07:18
Severity
Summary
In the Linux kernel, the following vulnerability has been resolved:
dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape
For raid456, if reshape is still in progress, then IO across reshape
position will wait for reshape to make progress. However, for dm-raid,
in following cases reshape will never make progress hence IO will hang:
1) the array is read-only;
2) MD_RECOVERY_WAIT is set;
3) MD_RECOVERY_FROZEN is set;
After commit c467e97f079f ("md/raid6: use valid sector values to determine
if an I/O should wait on the reshape") fix the problem that IO across
reshape position doesn't wait for reshape, the dm-raid test
shell/lvconvert-raid-reshape.sh start to hang:
[root@fedora ~]# cat /proc/979/stack
[<0>] wait_woken+0x7d/0x90
[<0>] raid5_make_request+0x929/0x1d70 [raid456]
[<0>] md_handle_request+0xc2/0x3b0 [md_mod]
[<0>] raid_map+0x2c/0x50 [dm_raid]
[<0>] __map_bio+0x251/0x380 [dm_mod]
[<0>] dm_submit_bio+0x1f0/0x760 [dm_mod]
[<0>] __submit_bio+0xc2/0x1c0
[<0>] submit_bio_noacct_nocheck+0x17f/0x450
[<0>] submit_bio_noacct+0x2bc/0x780
[<0>] submit_bio+0x70/0xc0
[<0>] mpage_readahead+0x169/0x1f0
[<0>] blkdev_readahead+0x18/0x30
[<0>] read_pages+0x7c/0x3b0
[<0>] page_cache_ra_unbounded+0x1ab/0x280
[<0>] force_page_cache_ra+0x9e/0x130
[<0>] page_cache_sync_ra+0x3b/0x110
[<0>] filemap_get_pages+0x143/0xa30
[<0>] filemap_read+0xdc/0x4b0
[<0>] blkdev_read_iter+0x75/0x200
[<0>] vfs_read+0x272/0x460
[<0>] ksys_read+0x7a/0x170
[<0>] __x64_sys_read+0x1c/0x30
[<0>] do_syscall_64+0xc6/0x230
[<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
This is because reshape can't make progress.
For md/raid, the problem doesn't exist because register new sync_thread
doesn't rely on the IO to be done any more:
1) If array is read-only, it can switch to read-write by ioctl/sysfs;
2) md/raid never set MD_RECOVERY_WAIT;
3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold
'reconfig_mutex', hence it can be cleared and reshape can continue by
sysfs api 'sync_action'.
However, I'm not sure yet how to avoid the problem in dm-raid yet. This
patch on the one hand make sure raid_message() can't change
sync_thread() through raid_message() after presuspend(), on the other
hand detect the above 3 cases before wait for IO do be done in
dm_suspend(), and let dm-raid requeue those IO.
References
Impacted products
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-raid.c",
"drivers/md/md.c",
"drivers/md/md.h",
"drivers/md/raid5.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5943a34bf6bab5801e08a55f63e1b8d5bc90dae1",
"status": "affected",
"version": "c467e97f079f0019870c314996fae952cc768e82",
"versionType": "git"
},
{
"lessThan": "a8d249d770cb357d16a2097b548d2e4c1c137304",
"status": "affected",
"version": "c467e97f079f0019870c314996fae952cc768e82",
"versionType": "git"
},
{
"lessThan": "41425f96d7aa59bc865f60f5dda3d7697b555677",
"status": "affected",
"version": "c467e97f079f0019870c314996fae952cc768e82",
"versionType": "git"
},
{
"status": "affected",
"version": "515d971cd26a40f710490d1566783f9c62b46d61",
"versionType": "git"
},
{
"status": "affected",
"version": "4ce431c297558e30baa9226243a15d818320742b",
"versionType": "git"
},
{
"lessThan": "6.2",
"status": "affected",
"version": "6.1.68",
"versionType": "semver"
},
{
"lessThan": "6.7",
"status": "affected",
"version": "6.6.7",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-raid.c",
"drivers/md/md.c",
"drivers/md/md.h",
"drivers/md/raid5.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.7"
},
{
"lessThan": "6.7",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D395D167-B806-45A5-9C34-38C8A1FE0F7B",
"versionEndExcluding": "6.7.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4C59BBC3-6495-4A77-9C82-55EC7CDF5E02",
"versionEndExcluding": "6.8.3",
"versionStartIncluding": "6.8",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape\n\nFor raid456, if reshape is still in progress, then IO across reshape\nposition will wait for reshape to make progress. However, for dm-raid,\nin following cases reshape will never make progress hence IO will hang:\n\n1) the array is read-only;\n2) MD_RECOVERY_WAIT is set;\n3) MD_RECOVERY_FROZEN is set;\n\nAfter commit c467e97f079f (\"md/raid6: use valid sector values to determine\nif an I/O should wait on the reshape\") fix the problem that IO across\nreshape position doesn\u0027t wait for reshape, the dm-raid test\nshell/lvconvert-raid-reshape.sh start to hang:\n\n[root@fedora ~]# cat /proc/979/stack\n[\u003c0\u003e] wait_woken+0x7d/0x90\n[\u003c0\u003e] raid5_make_request+0x929/0x1d70 [raid456]\n[\u003c0\u003e] md_handle_request+0xc2/0x3b0 [md_mod]\n[\u003c0\u003e] raid_map+0x2c/0x50 [dm_raid]\n[\u003c0\u003e] __map_bio+0x251/0x380 [dm_mod]\n[\u003c0\u003e] dm_submit_bio+0x1f0/0x760 [dm_mod]\n[\u003c0\u003e] __submit_bio+0xc2/0x1c0\n[\u003c0\u003e] submit_bio_noacct_nocheck+0x17f/0x450\n[\u003c0\u003e] submit_bio_noacct+0x2bc/0x780\n[\u003c0\u003e] submit_bio+0x70/0xc0\n[\u003c0\u003e] mpage_readahead+0x169/0x1f0\n[\u003c0\u003e] blkdev_readahead+0x18/0x30\n[\u003c0\u003e] read_pages+0x7c/0x3b0\n[\u003c0\u003e] page_cache_ra_unbounded+0x1ab/0x280\n[\u003c0\u003e] force_page_cache_ra+0x9e/0x130\n[\u003c0\u003e] page_cache_sync_ra+0x3b/0x110\n[\u003c0\u003e] filemap_get_pages+0x143/0xa30\n[\u003c0\u003e] filemap_read+0xdc/0x4b0\n[\u003c0\u003e] blkdev_read_iter+0x75/0x200\n[\u003c0\u003e] vfs_read+0x272/0x460\n[\u003c0\u003e] ksys_read+0x7a/0x170\n[\u003c0\u003e] __x64_sys_read+0x1c/0x30\n[\u003c0\u003e] do_syscall_64+0xc6/0x230\n[\u003c0\u003e] entry_SYSCALL_64_after_hwframe+0x6c/0x74\n\nThis is because reshape can\u0027t make progress.\n\nFor md/raid, the problem doesn\u0027t exist because register new sync_thread\ndoesn\u0027t rely on the IO to be done any more:\n\n1) If array is read-only, it can switch to read-write by ioctl/sysfs;\n2) md/raid never set MD_RECOVERY_WAIT;\n3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn\u0027t hold\n \u0027reconfig_mutex\u0027, hence it can be cleared and reshape can continue by\n sysfs api \u0027sync_action\u0027.\n\nHowever, I\u0027m not sure yet how to avoid the problem in dm-raid yet. This\npatch on the one hand make sure raid_message() can\u0027t change\nsync_thread() through raid_message() after presuspend(), on the other\nhand detect the above 3 cases before wait for IO do be done in\ndm_suspend(), and let dm-raid requeue those IO."
},
{
"lang": "es",
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: dm-raid456, md/raid456: soluciona un punto muerto para dm-raid456 mientras io concurre con reshape. Para raid456, si el reshape todav\u00eda est\u00e1 en progreso, entonces IO en la posici\u00f3n de reshape esperar\u00e1 remodelar para progresar. Sin embargo, para dm-raid, en los siguientes casos la remodelaci\u00f3n nunca progresar\u00e1, por lo que IO se bloquear\u00e1: 1) la matriz es de solo lectura; 2) MD_RECOVERY_WAIT est\u00e1 configurado; 3) MD_RECOVERY_FROZEN est\u00e1 configurado; Despu\u00e9s de confirmar c467e97f079f (\"md/raid6: use valores de sector v\u00e1lidos para determinar si una E/S debe esperar a la remodelaci\u00f3n\") solucione el problema de que IO en la posici\u00f3n de remodelaci\u00f3n no espera a la remodelaci\u00f3n, la prueba dm-raid shell/lvconvert -raid-reshape.sh comienza a colgarse: [root@fedora ~]# cat /proc/979/stack [\u0026lt;0\u0026gt;] wait_woken+0x7d/0x90 [\u0026lt;0\u0026gt;] raid5_make_request+0x929/0x1d70 [raid456] [\u0026lt;0 \u0026gt;] md_handle_request+0xc2/0x3b0 [md_mod] [\u0026lt;0\u0026gt;] raid_map+0x2c/0x50 [dm_raid] [\u0026lt;0\u0026gt;] __map_bio+0x251/0x380 [dm_mod] [\u0026lt;0\u0026gt;] dm_submit_bio+0x1f0/0x760 [dm_mod] [ \u0026lt;0\u0026gt;] __submit_bio+0xc2/0x1c0 [\u0026lt;0\u0026gt;] submit_bio_noacct_nocheck+0x17f/0x450 [\u0026lt;0\u0026gt;] submit_bio_noacct+0x2bc/0x780 [\u0026lt;0\u0026gt;] submit_bio+0x70/0xc0 [\u0026lt;0\u0026gt;] mpage_readahead+0x169/0x1f0 [ \u0026lt;0\u0026gt;] blkdev_readahead+0x18/0x30 [\u0026lt;0\u0026gt;] read_pages+0x7c/0x3b0 [\u0026lt;0\u0026gt;] page_cache_ra_unbounded+0x1ab/0x280 [\u0026lt;0\u0026gt;] force_page_cache_ra+0x9e/0x130 [\u0026lt;0\u0026gt;] page_cache_sync_ra+0x3b/0x110 [ \u0026lt;0\u0026gt;] filemap_get_pages+0x143/0xa30 [\u0026lt;0\u0026gt;] filemap_read+0xdc/0x4b0 [\u0026lt;0\u0026gt;] blkdev_read_iter+0x75/0x200 [\u0026lt;0\u0026gt;] vfs_read+0x272/0x460 [\u0026lt;0\u0026gt;] ksys_read+0x7a/0x170 [ \u0026lt;0\u0026gt;] __x64_sys_read+0x1c/0x30 [\u0026lt;0\u0026gt;] do_syscall_64+0xc6/0x230 [\u0026lt;0\u0026gt;] Entry_SYSCALL_64_after_hwframe+0x6c/0x74 Esto se debe a que la remodelaci\u00f3n no puede progresar. Para md/raid, el problema no existe porque registrar un nuevo sync_thread ya no depende de que se realice la IO: 1) Si la matriz es de solo lectura, puede cambiar a lectura-escritura mediante ioctl/sysfs; 2) md/raid nunca configur\u00f3 MD_RECOVERY_WAIT; 3) Si se configura MD_RECOVERY_FROZEN, mddev_suspend() no contiene \u0027reconfig_mutex\u0027, por lo tanto, se puede borrar y la remodelaci\u00f3n puede continuar mediante sysfs api \u0027sync_action\u0027. Sin embargo, todav\u00eda no estoy seguro de c\u00f3mo evitar el problema en dm-raid. Este parche, por un lado, garantiza que raid_message() no pueda cambiar sync_thread() a trav\u00e9s de raid_message() despu\u00e9s de presuspend(), por otro lado detecta los 3 casos anteriores antes de esperar a que IO se realice en dm_suspend(), y deja dm-raid pone en cola esas IO."
}
],
"id": "CVE-2024-26962",
"lastModified": "2026-06-17T07:18:48.267",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-26962",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T15:45:26.664282Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-05-01T06:15:12.527",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/41425f96d7aa59bc865f60f5dda3d7697b555677"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5943a34bf6bab5801e08a55f63e1b8d5bc90dae1"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a8d249d770cb357d16a2097b548d2e4c1c137304"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/41425f96d7aa59bc865f60f5dda3d7697b555677"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5943a34bf6bab5801e08a55f63e1b8d5bc90dae1"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a8d249d770cb357d16a2097b548d2e4c1c137304"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-667"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.