{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-26757", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-02-19T14:20:24.170Z", "datePublished": "2024-04-03T17:00:41.633Z", "dateUpdated": "2024-08-02T00:14:13.354Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-05-29T05:22:11.706Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Don't ignore read-only array in md_check_recovery()\n\nUsually if the array is not read-write, md_check_recovery() won't\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->ro\n mddev->ro = 0\n -> 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->ro = ro\n\n4) stop the array:\nraid_dtr\n md_stop\n stop_sync_thread\n set_bit(MD_RECOVERY_INTR, &mddev->recovery);\n md_wakeup_thread_directly(mddev->sync_thread);\n wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))\n\n5) sync thread done:\n md_do_sync\n set_bit(MD_RECOVERY_DONE, &mddev->recovery);\n md_wakeup_thread(mddev->thread);\n\n6) daemon thread can't unregister sync thread:\n md_check_recovery\n if (!md_is_rdwr(mddev) &&\n !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery))\n return;\n -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang;\n\nThe root cause is that dm-raid manipulate 'mddev->ro' 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 'mddev->ro' in dm-raid, hence let's fix\nthe problem the easy way for now to prevent dm-raid regression."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/md/md.c"], "versions": [{"version": "ecbfb9f118bc", "lessThan": "2ea169c5a0b1", "status": "affected", "versionType": "git"}, {"version": "ecbfb9f118bc", "lessThan": "55a48ad2db64", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/md/md.c"], "versions": [{"version": "4.8", "status": "affected"}, {"version": "0", "lessThan": "4.8", "status": "unaffected", "versionType": "custom"}, {"version": "6.7.7", "lessThanOrEqual": "6.7.*", "status": "unaffected", "versionType": "custom"}, {"version": "6.8", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "references": [{"url": "https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3"}, {"url": "https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b"}], "title": "md: Don't ignore read-only array in md_check_recovery()", "x_generator": {"engine": "bippy-a5840b7849dd"}}, "adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2024-26757", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-04-03T19:35:42.965370Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-06-04T17:48:28.099Z"}}, {"providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-02T00:14:13.354Z"}, "title": "CVE Program Container", "references": [{"url": "https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b", "tags": ["x_transferred"]}]}]}}

{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-26757", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-02-19T14:20:24.170Z", "datePublished": "2024-04-03T17:00:41.633Z", "dateUpdated": "2024-06-04T17:48:28.099Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-05-29T05:22:11.706Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Don't ignore read-only array in md_check_recovery()\n\nUsually if the array is not read-write, md_check_recovery() won't\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->ro\n mddev->ro = 0\n -> 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->ro = ro\n\n4) stop the array:\nraid_dtr\n md_stop\n stop_sync_thread\n set_bit(MD_RECOVERY_INTR, &mddev->recovery);\n md_wakeup_thread_directly(mddev->sync_thread);\n wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))\n\n5) sync thread done:\n md_do_sync\n set_bit(MD_RECOVERY_DONE, &mddev->recovery);\n md_wakeup_thread(mddev->thread);\n\n6) daemon thread can't unregister sync thread:\n md_check_recovery\n if (!md_is_rdwr(mddev) &&\n !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery))\n return;\n -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang;\n\nThe root cause is that dm-raid manipulate 'mddev->ro' 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 'mddev->ro' in dm-raid, hence let's fix\nthe problem the easy way for now to prevent dm-raid regression."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/md/md.c"], "versions": [{"version": "ecbfb9f118bc", "lessThan": "2ea169c5a0b1", "status": "affected", "versionType": "git"}, {"version": "ecbfb9f118bc", "lessThan": "55a48ad2db64", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/md/md.c"], "versions": [{"version": "4.8", "status": "affected"}, {"version": "0", "lessThan": "4.8", "status": "unaffected", "versionType": "custom"}, {"version": "6.7.7", "lessThanOrEqual": "6.7.*", "status": "unaffected", "versionType": "custom"}, {"version": "6.8", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "references": [{"url": "https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3"}, {"url": "https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b"}], "title": "md: Don't ignore read-only array in md_check_recovery()", "x_generator": {"engine": "bippy-a5840b7849dd"}}, "adp": [{"metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2024-26757", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-04-03T19:35:42.965370Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-05-23T19:01:21.882Z"}, "title": "CISA ADP Vulnrichment"}]}}

{"cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Don't ignore read-only array in md_check_recovery()\n\nUsually if the array is not read-write, md_check_recovery() won't\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->ro\n mddev->ro = 0\n -> 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->ro = ro\n\n4) stop the array:\nraid_dtr\n md_stop\n stop_sync_thread\n set_bit(MD_RECOVERY_INTR, &mddev->recovery);\n md_wakeup_thread_directly(mddev->sync_thread);\n wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))\n\n5) sync thread done:\n md_do_sync\n set_bit(MD_RECOVERY_DONE, &mddev->recovery);\n md_wakeup_thread(mddev->thread);\n\n6) daemon thread can't unregister sync thread:\n md_check_recovery\n if (!md_is_rdwr(mddev) &&\n !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery))\n return;\n -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang;\n\nThe root cause is that dm-raid manipulate 'mddev->ro' 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 'mddev->ro' in dm-raid, hence let's 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->ro mddev->ro = 0 -> 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->ro = ro 4) detiene la matriz: 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) hilo de sincronizaci\u00f3n realizado: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 6) el hilo del demonio no puede cancelar el registro del hilo de sincronizaci\u00f3n: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING no se puede borrar, por lo tanto el paso 4 se bloquea; La causa principal es que dm-raid manipula 'mddev->ro' 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 'mddev->ro' 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": "2024-04-03T17:24:18.150", "metrics": {}, "published": "2024-04-03T17:15:52.207", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis"}

{"bugzilla": {"description": "kernel: md: Don't ignore read-only array in md_check_recovery()", "id": "2273208", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2273208"}, "csaw": false, "cvss3": {"cvss3_base_score": "4.4", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "cwe": "CWE-20", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nmd: Don't ignore read-only array in md_check_recovery()\nUsually if the array is not read-write, md_check_recovery() won't\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.\nAfter commit f52f5c71f3d4 (\"md: fix stopping sync thread\"), following\nhang can be triggered by test shell/integrity-caching.sh:\n1) array is read-only. dm-raid update super block:\nrs_update_sbs\nro = mddev->ro\nmddev->ro = 0\n-> set array read-write\nmd_update_sb\n2) register new sync thread concurrently.\n3) dm-raid set array back to read-only:\nrs_update_sbs\nmddev->ro = ro\n4) stop the array:\nraid_dtr\nmd_stop\nstop_sync_thread\nset_bit(MD_RECOVERY_INTR, &mddev->recovery);\nmd_wakeup_thread_directly(mddev->sync_thread);\nwait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))\n5) sync thread done:\nmd_do_sync\nset_bit(MD_RECOVERY_DONE, &mddev->recovery);\nmd_wakeup_thread(mddev->thread);\n6) daemon thread can't unregister sync thread:\nmd_check_recovery\nif (!md_is_rdwr(mddev) &&\n!test_bit(MD_RECOVERY_NEEDED, &mddev->recovery))\nreturn;\n-> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang;\nThe root cause is that dm-raid manipulate 'mddev->ro' 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 'mddev->ro' in dm-raid, hence let's fix\nthe problem the easy way for now to prevent dm-raid regression."], "name": "CVE-2024-26757", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Under investigation", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Under investigation", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Under investigation", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Under investigation", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-04-03T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-26757\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-26757\nhttps://lore.kernel.org/linux-cve-announce/2024040304-CVE-2024-26757-7f96@gregkh/T"], "threat_severity": "Low", "upstream_fix": "kernel 6.7.7, kernel 6.8"}