gsd-2024-26755
Vulnerability from gsd
Modified
2024-02-20 06:02
Details
In the Linux kernel, the following vulnerability has been resolved: md: Don't suspend the array for interrupted reshape md_start_sync() will suspend the array if there are spares that can be added or removed from conf, however, if reshape is still in progress, this won't happen at all or data will be corrupted(remove_and_add_spares won't be called from md_choose_sync_action for reshape), hence there is no need to suspend the array if reshape is not done yet. Meanwhile, there is a potential deadlock for raid456: 1) reshape is interrupted; 2) set one of the disk WantReplacement, and add a new disk to the array, however, recovery won't start until the reshape is finished; 3) then issue an IO across reshpae position, this IO will wait for reshape to make progress; 4) continue to reshape, then md_start_sync() found there is a spare disk that can be added to conf, mddev_suspend() is called; Step 4 and step 3 is waiting for each other, deadlock triggered. Noted this problem is found by code review, and it's not reporduced yet. Fix this porblem by don't suspend the array for interrupted reshape, this is safe because conf won't be changed until reshape is done.
Aliases


To clipboard 

{
  "gsd": {
    "metadata": {
      "exploitCode": "unknown",
      "remediation": "unknown",
      "reportConfidence": "confirmed",
      "type": "vulnerability"
    },
    "osvSchema": {
      "aliases": [
        "CVE-2024-26755"
      ],
      "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Don\u0027t suspend the array for interrupted reshape\n\nmd_start_sync() will suspend the array if there are spares that can be\nadded or removed from conf, however, if reshape is still in progress,\nthis won\u0027t happen at all or data will be corrupted(remove_and_add_spares\nwon\u0027t be called from md_choose_sync_action for reshape), hence there is\nno need to suspend the array if reshape is not done yet.\n\nMeanwhile, there is a potential deadlock for raid456:\n\n1) reshape is interrupted;\n\n2) set one of the disk WantReplacement, and add a new disk to the array,\n   however, recovery won\u0027t start until the reshape is finished;\n\n3) then issue an IO across reshpae position, this IO will wait for\n   reshape to make progress;\n\n4) continue to reshape, then md_start_sync() found there is a spare disk\n   that can be added to conf, mddev_suspend() is called;\n\nStep 4 and step 3 is waiting for each other, deadlock triggered. Noted\nthis problem is found by code review, and it\u0027s not reporduced yet.\n\nFix this porblem by don\u0027t suspend the array for interrupted reshape,\nthis is safe because conf won\u0027t be changed until reshape is done.",
      "id": "GSD-2024-26755",
      "modified": "2024-02-20T06:02:29.253770Z",
      "schema_version": "1.4.0"
    }
  },
  "namespaces": {
    "cve.org": {
      "CVE_data_meta": {
        "ASSIGNER": "cve@kernel.org",
        "ID": "CVE-2024-26755",
        "STATE": "PUBLIC"
      },
      "affects": {
        "vendor": {
          "vendor_data": [
            {
              "product": {
                "product_data": [
                  {
                    "product_name": "Linux",
                    "version": {
                      "version_data": [
                        {
                          "version_affected": "\u003c",
                          "version_name": "bc08041b32ab",
                          "version_value": "60d6130d0ac1"
                        },
                        {
                          "version_value": "not down converted",
                          "x_cve_json_5_version_data": {
                            "defaultStatus": "affected",
                            "versions": [
                              {
                                "status": "affected",
                                "version": "6.7"
                              },
                              {
                                "lessThan": "6.7",
                                "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 suspend the array for interrupted reshape\n\nmd_start_sync() will suspend the array if there are spares that can be\nadded or removed from conf, however, if reshape is still in progress,\nthis won\u0027t happen at all or data will be corrupted(remove_and_add_spares\nwon\u0027t be called from md_choose_sync_action for reshape), hence there is\nno need to suspend the array if reshape is not done yet.\n\nMeanwhile, there is a potential deadlock for raid456:\n\n1) reshape is interrupted;\n\n2) set one of the disk WantReplacement, and add a new disk to the array,\n   however, recovery won\u0027t start until the reshape is finished;\n\n3) then issue an IO across reshpae position, this IO will wait for\n   reshape to make progress;\n\n4) continue to reshape, then md_start_sync() found there is a spare disk\n   that can be added to conf, mddev_suspend() is called;\n\nStep 4 and step 3 is waiting for each other, deadlock triggered. Noted\nthis problem is found by code review, and it\u0027s not reporduced yet.\n\nFix this porblem by don\u0027t suspend the array for interrupted reshape,\nthis is safe because conf won\u0027t be changed until reshape is done."
          }
        ]
      },
      "generator": {
        "engine": "bippy-d3b290d2becc"
      },
      "problemtype": {
        "problemtype_data": [
          {
            "description": [
              {
                "lang": "eng",
                "value": "n/a"
              }
            ]
          }
        ]
      },
      "references": {
        "reference_data": [
          {
            "name": "https://git.kernel.org/stable/c/60d6130d0ac1d883ed93c2a1e10aadb60967fd48",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/60d6130d0ac1d883ed93c2a1e10aadb60967fd48"
          },
          {
            "name": "https://git.kernel.org/stable/c/9e46c70e829bddc24e04f963471e9983a11598b7",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/9e46c70e829bddc24e04f963471e9983a11598b7"
          }
        ]
      }
    },
    "nvd.nist.gov": {
      "cve": {
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Don\u0027t suspend the array for interrupted reshape\n\nmd_start_sync() will suspend the array if there are spares that can be\nadded or removed from conf, however, if reshape is still in progress,\nthis won\u0027t happen at all or data will be corrupted(remove_and_add_spares\nwon\u0027t be called from md_choose_sync_action for reshape), hence there is\nno need to suspend the array if reshape is not done yet.\n\nMeanwhile, there is a potential deadlock for raid456:\n\n1) reshape is interrupted;\n\n2) set one of the disk WantReplacement, and add a new disk to the array,\n   however, recovery won\u0027t start until the reshape is finished;\n\n3) then issue an IO across reshpae position, this IO will wait for\n   reshape to make progress;\n\n4) continue to reshape, then md_start_sync() found there is a spare disk\n   that can be added to conf, mddev_suspend() is called;\n\nStep 4 and step 3 is waiting for each other, deadlock triggered. Noted\nthis problem is found by code review, and it\u0027s not reporduced yet.\n\nFix this porblem by don\u0027t suspend the array for interrupted reshape,\nthis is safe because conf won\u0027t be changed until reshape is done."
          }
        ],
        "id": "CVE-2024-26755",
        "lastModified": "2024-04-03T17:24:18.150",
        "metrics": {},
        "published": "2024-04-03T17:15:52.103",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/60d6130d0ac1d883ed93c2a1e10aadb60967fd48"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/9e46c70e829bddc24e04f963471e9983a11598b7"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Awaiting Analysis"
      }
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.