GHSA-C8CC-57PQ-936R

Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-08-27 21:31
VLAI?
Details

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

md: fix resync softlockup when bitmap size is less than array size

Is is reported that for dm-raid10, lvextend + lvchange --syncaction will trigger following softlockup:

kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976] CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1 RIP: 0010:_raw_spin_unlock_irq+0x13/0x30 Call Trace: md_bitmap_start_sync+0x6b/0xf0 raid10_sync_request+0x25c/0x1b40 [raid10] md_do_sync+0x64b/0x1020 md_thread+0xa7/0x170 kthread+0xcf/0x100 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1a/0x30

And the detailed process is as follows:

md_do_sync j = mddev->resync_min while (j < max_sectors) sectors = raid10_sync_request(mddev, j, &skipped) if (!md_bitmap_start_sync(..., &sync_blocks)) // md_bitmap_start_sync set sync_blocks to 0 return sync_blocks + sectors_skippe; // sectors = 0; j += sectors; // j never change

Root cause is that commit 301867b1c168 ("md/raid10: check slab-out-of-bounds in md_bitmap_get_counter") return early from md_bitmap_get_counter(), without setting returned blocks.

Fix this problem by always set returned blocks from md_bitmap_get_counter"(), as it used to be.

Noted that this patch just fix the softlockup problem in kernel, the case that bitmap size doesn't match array size still need to be fixed.

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-38598"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-19T14:15:19Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix resync softlockup when bitmap size is less than array size\n\nIs is reported that for dm-raid10, lvextend + lvchange --syncaction will\ntrigger following softlockup:\n\nkernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]\nCPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1\nRIP: 0010:_raw_spin_unlock_irq+0x13/0x30\nCall Trace:\n \u003cTASK\u003e\n md_bitmap_start_sync+0x6b/0xf0\n raid10_sync_request+0x25c/0x1b40 [raid10]\n md_do_sync+0x64b/0x1020\n md_thread+0xa7/0x170\n kthread+0xcf/0x100\n ret_from_fork+0x30/0x50\n ret_from_fork_asm+0x1a/0x30\n\nAnd the detailed process is as follows:\n\nmd_do_sync\n j = mddev-\u003eresync_min\n while (j \u003c max_sectors)\n  sectors = raid10_sync_request(mddev, j, \u0026skipped)\n   if (!md_bitmap_start_sync(..., \u0026sync_blocks))\n    // md_bitmap_start_sync set sync_blocks to 0\n    return sync_blocks + sectors_skippe;\n  // sectors = 0;\n  j += sectors;\n  // j never change\n\nRoot cause is that commit 301867b1c168 (\"md/raid10: check\nslab-out-of-bounds in md_bitmap_get_counter\") return early from\nmd_bitmap_get_counter(), without setting returned blocks.\n\nFix this problem by always set returned blocks from\nmd_bitmap_get_counter\"(), as it used to be.\n\nNoted that this patch just fix the softlockup problem in kernel, the\ncase that bitmap size doesn\u0027t match array size still need to be fixed.",
  "id": "GHSA-c8cc-57pq-936r",
  "modified": "2024-08-27T21:31:13Z",
  "published": "2024-06-19T15:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38598"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3f5b73ef8fd6268cbc968b308d8eafe56fda97f3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/43771597feba89a839c5f893716df88ae5c237ce"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5817f43ae1a118855676f57ef7ab50e37eac7482"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/69296914bfd508c85935bf5f711cad9b0fe78492"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/71e8e4f288e74a896b6d9cd194f3bab12bd7a10f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8bbc71315e0ae4bb7e37f8d43b915e1cb01a481b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c9566b812c8f66160466cc1e29df6d3646add0b1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d4b9c764d48fa41caa24cfb4275f3aa9fb4bd798"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f0e729af2eb6bee9eb58c4df1087f14ebaefe26b"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
    }
  ],
  "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.




Sightings

Author Source Type Date

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.