ghsa-fh88-v2mj-cp79
Vulnerability from github
Published
2024-10-21 15:32
Modified
2025-01-17 15:32
Severity ?
5.5 (Medium) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Details

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

erofs: handle overlapped pclusters out of crafted images properly

syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os.

After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below:

Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ...

Here, extent 0/1 are physically overlapped although it's entirely impossible for normal filesystem images generated by mkfs.

First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits.

Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness.

Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidy up struct z_erofs_bvec") for simplicity although it shouldn't be any difference.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-47736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T13:15:03Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: handle overlapped pclusters out of crafted images properly\n\nsyzbot reported a task hang issue due to a deadlock case where it is\nwaiting for the folio lock of a cached folio that will be used for\ncache I/Os.\n\nAfter looking into the crafted fuzzed image, I found it\u0027s formed with\nseveral overlapped big pclusters as below:\n\n Ext:   logical offset   |  length :     physical offset    |  length\n   0:        0..   16384 |   16384 :     151552..    167936 |   16384\n   1:    16384..   32768 |   16384 :     155648..    172032 |   16384\n   2:    32768..   49152 |   16384 :  537223168.. 537239552 |   16384\n...\n\nHere, extent 0/1 are physically overlapped although it\u0027s entirely\n_impossible_ for normal filesystem images generated by mkfs.\n\nFirst, managed folios containing compressed data will be marked as\nup-to-date and then unlocked immediately (unlike in-place folios) when\ncompressed I/Os are complete.  If physical blocks are not submitted in\nthe incremental order, there should be separate BIOs to avoid dependency\nissues.  However, the current code mis-arranges z_erofs_fill_bio_vec()\nand BIO submission which causes unexpected BIO waits.\n\nSecond, managed folios will be connected to their own pclusters for\nefficient inter-queries.  However, this is somewhat hard to implement\neasily if overlapped big pclusters exist.  Again, these only appear in\nfuzzed images so let\u0027s simply fall back to temporary short-lived pages\nfor correctness.\n\nAdditionally, it justifies that referenced managed folios cannot be\ntruncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy\nup `struct z_erofs_bvec`\") for simplicity although it shouldn\u0027t be any\ndifference.",
  "id": "GHSA-fh88-v2mj-cp79",
  "modified": "2025-01-17T15:32:32Z",
  "published": "2024-10-21T15:32:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47736"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1bf7e414cac303c9aec1be67872e19be8b64980c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9cfa199bcbbbba31cbf97b2786f44f4464f3f29a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9e2f9d34dd12e6e5b244ec488bcebd0c2d566c50"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b9b30af0e86ffb485301ecd83b9129c9dfb7ebf8"
    }
  ],
  "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 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.