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

GHSA-3M73-M9XC-48PV

Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-12-23 15:30
VLAI
Details

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

dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape

For raid456, if reshape is still in progress, then IO across reshape position will wait for reshape to make progress. However, for dm-raid, in following cases reshape will never make progress hence IO will hang:

1) the array is read-only; 2) MD_RECOVERY_WAIT is set; 3) MD_RECOVERY_FROZEN is set;

After commit c467e97f079f ("md/raid6: use valid sector values to determine if an I/O should wait on the reshape") fix the problem that IO across reshape position doesn't wait for reshape, the dm-raid test shell/lvconvert-raid-reshape.sh start to hang:

[root@fedora ~]# cat /proc/979/stack [<0>] wait_woken+0x7d/0x90 [<0>] raid5_make_request+0x929/0x1d70 [raid456] [<0>] md_handle_request+0xc2/0x3b0 [md_mod] [<0>] raid_map+0x2c/0x50 [dm_raid] [<0>] __map_bio+0x251/0x380 [dm_mod] [<0>] dm_submit_bio+0x1f0/0x760 [dm_mod] [<0>] __submit_bio+0xc2/0x1c0 [<0>] submit_bio_noacct_nocheck+0x17f/0x450 [<0>] submit_bio_noacct+0x2bc/0x780 [<0>] submit_bio+0x70/0xc0 [<0>] mpage_readahead+0x169/0x1f0 [<0>] blkdev_readahead+0x18/0x30 [<0>] read_pages+0x7c/0x3b0 [<0>] page_cache_ra_unbounded+0x1ab/0x280 [<0>] force_page_cache_ra+0x9e/0x130 [<0>] page_cache_sync_ra+0x3b/0x110 [<0>] filemap_get_pages+0x143/0xa30 [<0>] filemap_read+0xdc/0x4b0 [<0>] blkdev_read_iter+0x75/0x200 [<0>] vfs_read+0x272/0x460 [<0>] ksys_read+0x7a/0x170 [<0>] __x64_sys_read+0x1c/0x30 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74

This is because reshape can't make progress.

For md/raid, the problem doesn't exist because register new sync_thread doesn't rely on the IO to be done any more:

1) If array is read-only, it can switch to read-write by ioctl/sysfs; 2) md/raid never set MD_RECOVERY_WAIT; 3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold 'reconfig_mutex', hence it can be cleared and reshape can continue by sysfs api 'sync_action'.

However, I'm not sure yet how to avoid the problem in dm-raid yet. This patch on the one hand make sure raid_message() can't change sync_thread() through raid_message() after presuspend(), on the other hand detect the above 3 cases before wait for IO do be done in dm_suspend(), and let dm-raid requeue those IO.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-26962"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-01T06:15:12Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape\n\nFor raid456, if reshape is still in progress, then IO across reshape\nposition will wait for reshape to make progress. However, for dm-raid,\nin following cases reshape will never make progress hence IO will hang:\n\n1) the array is read-only;\n2) MD_RECOVERY_WAIT is set;\n3) MD_RECOVERY_FROZEN is set;\n\nAfter commit c467e97f079f (\"md/raid6: use valid sector values to determine\nif an I/O should wait on the reshape\") fix the problem that IO across\nreshape position doesn\u0027t wait for reshape, the dm-raid test\nshell/lvconvert-raid-reshape.sh start to hang:\n\n[root@fedora ~]# cat /proc/979/stack\n[\u003c0\u003e] wait_woken+0x7d/0x90\n[\u003c0\u003e] raid5_make_request+0x929/0x1d70 [raid456]\n[\u003c0\u003e] md_handle_request+0xc2/0x3b0 [md_mod]\n[\u003c0\u003e] raid_map+0x2c/0x50 [dm_raid]\n[\u003c0\u003e] __map_bio+0x251/0x380 [dm_mod]\n[\u003c0\u003e] dm_submit_bio+0x1f0/0x760 [dm_mod]\n[\u003c0\u003e] __submit_bio+0xc2/0x1c0\n[\u003c0\u003e] submit_bio_noacct_nocheck+0x17f/0x450\n[\u003c0\u003e] submit_bio_noacct+0x2bc/0x780\n[\u003c0\u003e] submit_bio+0x70/0xc0\n[\u003c0\u003e] mpage_readahead+0x169/0x1f0\n[\u003c0\u003e] blkdev_readahead+0x18/0x30\n[\u003c0\u003e] read_pages+0x7c/0x3b0\n[\u003c0\u003e] page_cache_ra_unbounded+0x1ab/0x280\n[\u003c0\u003e] force_page_cache_ra+0x9e/0x130\n[\u003c0\u003e] page_cache_sync_ra+0x3b/0x110\n[\u003c0\u003e] filemap_get_pages+0x143/0xa30\n[\u003c0\u003e] filemap_read+0xdc/0x4b0\n[\u003c0\u003e] blkdev_read_iter+0x75/0x200\n[\u003c0\u003e] vfs_read+0x272/0x460\n[\u003c0\u003e] ksys_read+0x7a/0x170\n[\u003c0\u003e] __x64_sys_read+0x1c/0x30\n[\u003c0\u003e] do_syscall_64+0xc6/0x230\n[\u003c0\u003e] entry_SYSCALL_64_after_hwframe+0x6c/0x74\n\nThis is because reshape can\u0027t make progress.\n\nFor md/raid, the problem doesn\u0027t exist because register new sync_thread\ndoesn\u0027t rely on the IO to be done any more:\n\n1) If array is read-only, it can switch to read-write by ioctl/sysfs;\n2) md/raid never set MD_RECOVERY_WAIT;\n3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn\u0027t hold\n   \u0027reconfig_mutex\u0027, hence it can be cleared and reshape can continue by\n   sysfs api \u0027sync_action\u0027.\n\nHowever, I\u0027m not sure yet how to avoid the problem in dm-raid yet. This\npatch on the one hand make sure raid_message() can\u0027t change\nsync_thread() through raid_message() after presuspend(), on the other\nhand detect the above 3 cases before wait for IO do be done in\ndm_suspend(), and let dm-raid requeue those IO.",
  "id": "GHSA-3m73-m9xc-48pv",
  "modified": "2024-12-23T15:30:46Z",
  "published": "2024-05-01T06:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26962"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/41425f96d7aa59bc865f60f5dda3d7697b555677"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5943a34bf6bab5801e08a55f63e1b8d5bc90dae1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a8d249d770cb357d16a2097b548d2e4c1c137304"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



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.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.