ghsa-85g7-5359-r834
Vulnerability from github
Published
2024-04-03 18:30
Modified
2024-04-03 18:30
Details

In the Linux kernel, the following vulnerability has been resolved:

md: Don't register sync_thread for reshape directly

Currently, if reshape is interrupted, then reassemble the array will register sync_thread directly from pers->run(), in this case 'MD_RECOVERY_RUNNING' is set directly, however, there is no guarantee that md_do_sync() will be executed, hence stop_sync_thread() will hang because 'MD_RECOVERY_RUNNING' can't be cleared.

Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE, however, following hang can still be triggered by dm-raid test shell/lvconvert-raid-reshape.sh occasionally:

[root@fedora ~]# cat /proc/1982/stack [<0>] stop_sync_thread+0x1ab/0x270 [md_mod] [<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [<0>] raid_presuspend+0x1e/0x70 [dm_raid] [<0>] dm_table_presuspend_targets+0x40/0xb0 [dm_mod] [<0>] __dm_destroy+0x2a5/0x310 [dm_mod] [<0>] dm_destroy+0x16/0x30 [dm_mod] [<0>] dev_remove+0x165/0x290 [dm_mod] [<0>] ctl_ioctl+0x4bb/0x7b0 [dm_mod] [<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod] [<0>] vfs_ioctl+0x21/0x60 [<0>] __x64_sys_ioctl+0xb9/0xe0 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74

Meanwhile mddev->recovery is: MD_RECOVERY_RUNNING | MD_RECOVERY_INTR | MD_RECOVERY_RESHAPE | MD_RECOVERY_FROZEN

Fix this problem by remove the code to register sync_thread directly from raid10 and raid5. And let md_check_recovery() to register sync_thread.

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2024-26756"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-03T17:15:52Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Don\u0027t register sync_thread for reshape directly\n\nCurrently, if reshape is interrupted, then reassemble the array will\nregister sync_thread directly from pers-\u003erun(), in this case\n\u0027MD_RECOVERY_RUNNING\u0027 is set directly, however, there is no guarantee\nthat md_do_sync() will be executed, hence stop_sync_thread() will hang\nbecause \u0027MD_RECOVERY_RUNNING\u0027 can\u0027t be cleared.\n\nLast patch make sure that md_do_sync() will set MD_RECOVERY_DONE,\nhowever, following hang can still be triggered by dm-raid test\nshell/lvconvert-raid-reshape.sh occasionally:\n\n[root@fedora ~]# cat /proc/1982/stack\n[\u003c0\u003e] stop_sync_thread+0x1ab/0x270 [md_mod]\n[\u003c0\u003e] md_frozen_sync_thread+0x5c/0xa0 [md_mod]\n[\u003c0\u003e] raid_presuspend+0x1e/0x70 [dm_raid]\n[\u003c0\u003e] dm_table_presuspend_targets+0x40/0xb0 [dm_mod]\n[\u003c0\u003e] __dm_destroy+0x2a5/0x310 [dm_mod]\n[\u003c0\u003e] dm_destroy+0x16/0x30 [dm_mod]\n[\u003c0\u003e] dev_remove+0x165/0x290 [dm_mod]\n[\u003c0\u003e] ctl_ioctl+0x4bb/0x7b0 [dm_mod]\n[\u003c0\u003e] dm_ctl_ioctl+0x11/0x20 [dm_mod]\n[\u003c0\u003e] vfs_ioctl+0x21/0x60\n[\u003c0\u003e] __x64_sys_ioctl+0xb9/0xe0\n[\u003c0\u003e] do_syscall_64+0xc6/0x230\n[\u003c0\u003e] entry_SYSCALL_64_after_hwframe+0x6c/0x74\n\nMeanwhile mddev-\u003erecovery is:\nMD_RECOVERY_RUNNING |\nMD_RECOVERY_INTR |\nMD_RECOVERY_RESHAPE |\nMD_RECOVERY_FROZEN\n\nFix this problem by remove the code to register sync_thread directly\nfrom raid10 and raid5. And let md_check_recovery() to register\nsync_thread.",
  "id": "GHSA-85g7-5359-r834",
  "modified": "2024-04-03T18:30:42Z",
  "published": "2024-04-03T18:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26756"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/13b520fb62b772e408f9b79c5fe18ad414e90417"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ad39c08186f8a0f221337985036ba86731d6aafe"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading...

Loading...

Loading...
  • 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.