GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

CVE-2024-26757 (GCVE-0-2024-26757)

Vulnerability from cvelistv5 – Published: 2024-04-03 17:00 – Updated: 2026-05-11 20:03
VLAI
Title
md: Don't ignore read-only array in md_check_recovery()
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.
Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2024-04-03 19:35 UTC
CWE
  • CWE-404 - Improper Resource Shutdown or Release
Assigner
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: ecbfb9f118bce49f571675929160e4ecef91cc8a , < 2ea169c5a0b1134d573d07fc27a16f327ad0e7d3 (git)
Affected: ecbfb9f118bce49f571675929160e4ecef91cc8a , < 55a48ad2db64737f7ffc0407634218cc6e4c513b (git)
guessed Create a notification for this product.
Linux Linux Affected: 4.8
Unaffected: 0 , < 4.8 (semver)
Unaffected: 6.7.7 , ≤ 6.7.* (semver)
Unaffected: 6.8 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "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"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2024-26757",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-04-03T19:35:42.965370Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-404",
                "description": "CWE-404 Improper Resource Shutdown or Release",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-11-06T20:23:13.287Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T00:14:13.354Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "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"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.7.7",
                  "versionStartIncluding": "4.8",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.8",
                  "versionStartIncluding": "4.8",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "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."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T20:03:35.167Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3"
        },
        {
          "url": "https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b"
        }
      ],
      "title": "md: Don\u0027t ignore read-only array in md_check_recovery()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-26757",
    "datePublished": "2024-04-03T17:00:41.633Z",
    "dateReserved": "2024-02-19T14:20:24.170Z",
    "dateUpdated": "2026-05-11T20:03:35.167Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-26757",
      "date": "2026-09-13",
      "epss": "0.00209",
      "percentile": "0.11139"
    },
    "fkie_nvd": {
      "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": "2024-11-21T09:03:00.147",
      "metrics": "{\"cvssMetricV31\": [{\"source\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"type\": \"Secondary\", \"cvssData\": {\"version\": \"3.1\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\", \"baseScore\": 5.5, \"baseSeverity\": \"MEDIUM\", \"attackVector\": \"LOCAL\", \"attackComplexity\": \"LOW\", \"privilegesRequired\": \"LOW\", \"userInteraction\": \"NONE\", \"scope\": \"UNCHANGED\", \"confidentialityImpact\": \"NONE\", \"integrityImpact\": \"NONE\", \"availabilityImpact\": \"HIGH\"}, \"exploitabilityScore\": 1.8, \"impactScore\": 3.6}]}",
      "published": "2024-04-03T17:15:52.207",
      "references": "[{\"url\": \"https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}]",
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Awaiting Analysis",
      "weaknesses": "[{\"source\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"type\": \"Secondary\", \"description\": [{\"lang\": \"en\", \"value\": \"CWE-404\"}]}]"
    },
    "microsoft_vex": {
      "current_release_date": "2026-08-10T14:42:35.000Z",
      "cve": "CVE-2024-26757",
      "id": "msrc_CVE-2024-26757",
      "initial_release_date": "2025-09-03T22:35:55.000Z",
      "product_status:known_affected": "22",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "md: Don\u0027t ignore read-only array in md_check_recovery()",
      "url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2024-26757.json",
      "version": "19"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-26757\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-04-03T17:15:52.207\",\"lastModified\":\"2026-06-17T07:18:16.047\",\"vulnStatus\":\"Analyzed\",\"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.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"drivers/md/md.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"ecbfb9f118bce49f571675929160e4ecef91cc8a\",\"lessThan\":\"2ea169c5a0b1134d573d07fc27a16f327ad0e7d3\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"ecbfb9f118bce49f571675929160e4ecef91cc8a\",\"lessThan\":\"55a48ad2db64737f7ffc0407634218cc6e4c513b\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"drivers/md/md.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"4.8\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"4.8\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.7.7\",\"lessThanOrEqual\":\"6.7.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.8\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2024-04-03T19:35:42.965370Z\",\"id\":\"CVE-2024-26757\",\"options\":[{\"exploitation\":\"none\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"partial\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-404\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.8\",\"versionEndExcluding\":\"6.7.7\",\"matchCriteriaId\":\"EE20C08B-77CC-4CF7-A5CD-5157B5F7C0F1\"},{\"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\"}]}]}],\"references\":[{\"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\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"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\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]}]}}",
    "redhat_vex": {
      "aggregate_severity": "Low",
      "current_release_date": "2026-06-28T07:49:49+00:00",
      "cve": "CVE-2024-26757",
      "id": "CVE-2024-26757",
      "initial_release_date": "2024-04-03T00:00:00+00:00",
      "product_status:fixed": "280",
      "product_status:known_affected": "112",
      "product_status:known_not_affected": "8",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: md: Don\u0027t ignore read-only array in md_check_recovery()",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-26757.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-08-31T00:44:54Z",
      "cve": "CVE-2024-26757",
      "id": "CVE-2024-26757",
      "initial_release_date": "2024-04-10T02:16:33Z",
      "product_status:known_affected": "172",
      "product_status:known_not_affected": "144",
      "product_status:recommended": "218",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2024-26757",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-26757.json",
      "version": "42"
    },
    "vulnrichment": {
      "containers": "{\"adp\": [{\"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\"]}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2024-08-02T00:14:13.354Z\"}}, {\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 5.5, \"attackVector\": \"LOCAL\", \"baseSeverity\": \"MEDIUM\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\", \"integrityImpact\": \"NONE\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"HIGH\", \"privilegesRequired\": \"LOW\", \"confidentialityImpact\": \"NONE\"}}, {\"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\"}}}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-404\", \"description\": \"CWE-404 Improper Resource Shutdown or Release\"}]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-05-23T19:01:21.882Z\"}}], \"cna\": {\"title\": \"md: Don\u0027t ignore read-only array in md_check_recovery()\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"ecbfb9f118bce49f571675929160e4ecef91cc8a\", \"lessThan\": \"2ea169c5a0b1134d573d07fc27a16f327ad0e7d3\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"ecbfb9f118bce49f571675929160e4ecef91cc8a\", \"lessThan\": \"55a48ad2db64737f7ffc0407634218cc6e4c513b\", \"versionType\": \"git\"}], \"programFiles\": [\"drivers/md/md.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"4.8\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"4.8\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"6.7.7\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.7.*\"}, {\"status\": \"unaffected\", \"version\": \"6.8\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"drivers/md/md.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3\"}, {\"url\": \"https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"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.\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.7.7\", \"versionStartIncluding\": \"4.8\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.8\", \"versionStartIncluding\": \"4.8\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2026-05-11T20:03:35.167Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2024-26757\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-05-11T20:03:35.167Z\", \"dateReserved\": \"2024-02-19T14:20:24.170Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-04-03T17:00:41.633Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





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.


Detection rules are retrieved from Rulezet.