FKIE_CVE-2024-26757
Vulnerability from fkie_nvd - Published: 2024-04-03 17:15 - Updated: 2026-06-17 07:18
Severity
Summary
In the Linux kernel, the following vulnerability has been resolved:
md: Don't ignore read-only array in md_check_recovery()
Usually if the array is not read-write, md_check_recovery() won't
register new sync_thread in the first place. And if the array is
read-write and sync_thread is registered, md_set_readonly() will
unregister sync_thread before setting the array read-only. md/raid
follow this behavior hence there is no problem.
After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following
hang can be triggered by test shell/integrity-caching.sh:
1) array is read-only. dm-raid update super block:
rs_update_sbs
ro = mddev->ro
mddev->ro = 0
-> set array read-write
md_update_sb
2) register new sync thread concurrently.
3) dm-raid set array back to read-only:
rs_update_sbs
mddev->ro = ro
4) stop the array:
raid_dtr
md_stop
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))
5) sync thread done:
md_do_sync
set_bit(MD_RECOVERY_DONE, &mddev->recovery);
md_wakeup_thread(mddev->thread);
6) daemon thread can't unregister sync thread:
md_check_recovery
if (!md_is_rdwr(mddev) &&
!test_bit(MD_RECOVERY_NEEDED, &mddev->recovery))
return;
-> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang;
The root cause is that dm-raid manipulate 'mddev->ro' by itself,
however, dm-raid really should stop sync thread before setting the
array read-only. Unfortunately, I need to read more code before I
can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix
the problem the easy way for now to prevent dm-raid regression.
References
Impacted products
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.8 | |
| linux | linux_kernel | 6.8 | |
| linux | linux_kernel | 6.8 | |
| linux | linux_kernel | 6.8 | |
| linux | linux_kernel | 6.8 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/md/md.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "2ea169c5a0b1134d573d07fc27a16f327ad0e7d3",
"status": "affected",
"version": "ecbfb9f118bce49f571675929160e4ecef91cc8a",
"versionType": "git"
},
{
"lessThan": "55a48ad2db64737f7ffc0407634218cc6e4c513b",
"status": "affected",
"version": "ecbfb9f118bce49f571675929160e4ecef91cc8a",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/md/md.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.8"
},
{
"lessThan": "4.8",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.8",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "EE20C08B-77CC-4CF7-A5CD-5157B5F7C0F1",
"versionEndExcluding": "6.7.7",
"versionStartIncluding": "4.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc1:*:*:*:*:*:*",
"matchCriteriaId": "B9F4EA73-0894-400F-A490-3A397AB7A517",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:*",
"matchCriteriaId": "056BD938-0A27-4569-B391-30578B309EE3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:*",
"matchCriteriaId": "F02056A5-B362-4370-9FF8-6F0BD384D520",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc4:*:*:*:*:*:*",
"matchCriteriaId": "62075ACE-B2A0-4B16-829D-B3DA5AE5CC41",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc5:*:*:*:*:*:*",
"matchCriteriaId": "A780F817-2A77-4130-A9B7-5C25606314E3",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Don\u0027t ignore read-only array in md_check_recovery()\n\nUsually if the array is not read-write, md_check_recovery() won\u0027t\nregister new sync_thread in the first place. And if the array is\nread-write and sync_thread is registered, md_set_readonly() will\nunregister sync_thread before setting the array read-only. md/raid\nfollow this behavior hence there is no problem.\n\nAfter commit f52f5c71f3d4 (\"md: fix stopping sync thread\"), following\nhang can be triggered by test shell/integrity-caching.sh:\n\n1) array is read-only. dm-raid update super block:\nrs_update_sbs\n ro = mddev-\u003ero\n mddev-\u003ero = 0\n -\u003e set array read-write\n md_update_sb\n\n2) register new sync thread concurrently.\n\n3) dm-raid set array back to read-only:\nrs_update_sbs\n mddev-\u003ero = ro\n\n4) stop the array:\nraid_dtr\n md_stop\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\n5) sync thread done:\n md_do_sync\n set_bit(MD_RECOVERY_DONE, \u0026mddev-\u003erecovery);\n md_wakeup_thread(mddev-\u003ethread);\n\n6) daemon thread can\u0027t unregister sync thread:\n md_check_recovery\n if (!md_is_rdwr(mddev) \u0026\u0026\n !test_bit(MD_RECOVERY_NEEDED, \u0026mddev-\u003erecovery))\n return;\n -\u003e -\u003e MD_RECOVERY_RUNNING can\u0027t be cleared, hence step 4 hang;\n\nThe root cause is that dm-raid manipulate \u0027mddev-\u003ero\u0027 by itself,\nhowever, dm-raid really should stop sync thread before setting the\narray read-only. Unfortunately, I need to read more code before I\ncan refacter the handler of \u0027mddev-\u003ero\u0027 in dm-raid, hence let\u0027s fix\nthe problem the easy way for now to prevent dm-raid regression."
},
{
"lang": "es",
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: md: No ignorar la matriz de solo lectura en md_check_recovery() Generalmente, si la matriz no es de lectura y escritura, md_check_recovery() no registrar\u00e1 un nuevo sync_thread en primer lugar. Y si la matriz es de lectura y escritura y sync_thread est\u00e1 registrado, md_set_readonly() cancelar\u00e1 el registro de sync_thread antes de configurar la matriz como de solo lectura. md/raid sigue este comportamiento, por lo que no hay problema. Despu\u00e9s de commit f52f5c71f3d4 (\"md: arreglar la detenci\u00f3n del hilo de sincronizaci\u00f3n\"), el siguiente bloqueo puede activarse mediante test shell/integrity-caching.sh: 1) la matriz es de solo lectura. Superbloque de actualizaci\u00f3n dm-raid: rs_update_sbs ro = mddev-\u0026gt;ro mddev-\u0026gt;ro = 0 -\u0026gt; establecer matriz de lectura y escritura md_update_sb 2) registrar un nuevo hilo de sincronizaci\u00f3n simult\u00e1neamente. 3) dm-raid vuelve a configurar la matriz en solo lectura: rs_update_sbs mddev-\u0026gt;ro = ro 4) detiene la matriz: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, \u0026amp;mddev-\u0026gt;recovery); md_wakeup_thread_directly(mddev-\u0026gt;sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, \u0026amp;mddev-\u0026gt;recovery)) 5) hilo de sincronizaci\u00f3n realizado: md_do_sync set_bit(MD_RECOVERY_DONE, \u0026amp;mddev-\u0026gt;recovery); md_wakeup_thread(mddev-\u0026gt;thread); 6) el hilo del demonio no puede cancelar el registro del hilo de sincronizaci\u00f3n: md_check_recovery if (!md_is_rdwr(mddev) \u0026amp;\u0026amp; !test_bit(MD_RECOVERY_NEEDED, \u0026amp;mddev-\u0026gt;recovery)) return; -\u0026gt; -\u0026gt; MD_RECOVERY_RUNNING no se puede borrar, por lo tanto el paso 4 se bloquea; La causa principal es que dm-raid manipula \u0027mddev-\u0026gt;ro\u0027 por s\u00ed solo; sin embargo, dm-raid realmente deber\u00eda detener el hilo de sincronizaci\u00f3n antes de configurar la matriz como de solo lectura. Desafortunadamente, necesito leer m\u00e1s c\u00f3digo antes de poder refactorizar el controlador de \u0027mddev-\u0026gt;ro\u0027 en dm-raid, por lo tanto, solucionemos el problema de la manera m\u00e1s f\u00e1cil por ahora para evitar la regresi\u00f3n de dm-raid."
}
],
"id": "CVE-2024-26757",
"lastModified": "2026-06-17T07:18:16.047",
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-26757",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-04-03T19:35:42.965370Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-04-03T17:15:52.207",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-404"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
Loading…
Loading…
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.
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.
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.
Loading…
Loading…