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

GHSA-9244-GHQ8-MVQ4

Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-19 15:31
VLAI
Details

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

erofs: wake up all waiters after z_erofs_lzma_head ready

When the user mounts the erofs second times, the decompression thread may hung. The problem happens due to a sequence of steps like the following:

1) Task A called z_erofs_load_lzma_config which obtain all of the node from the z_erofs_lzma_head.

2) At this time, task B called the z_erofs_lzma_decompress and wanted to get a node. But the z_erofs_lzma_head was empty, the Task B had to sleep.

3) Task A release nodes and push nodes into the z_erofs_lzma_head. But task B was still sleeping.

One example report when the hung happens: task:kworker/u3:1 state:D stack:14384 pid: 86 ppid: 2 flags:0x00004000 Workqueue: erofs_unzipd z_erofs_decompressqueue_work Call Trace: __schedule+0x281/0x760 schedule+0x49/0xb0 z_erofs_lzma_decompress+0x4bc/0x580 ? cpu_core_flags+0x10/0x10 z_erofs_decompress_pcluster+0x49b/0xba0 ? __update_load_avg_se+0x2b0/0x330 ? __update_load_avg_se+0x2b0/0x330 ? update_load_avg+0x5f/0x690 ? update_load_avg+0x5f/0x690 ? set_next_entity+0xbd/0x110 ? _raw_spin_unlock+0xd/0x20 z_erofs_decompress_queue.isra.0+0x2e/0x50 z_erofs_decompressqueue_work+0x30/0x60 process_one_work+0x1d3/0x3a0 worker_thread+0x45/0x3a0 ? process_one_work+0x3a0/0x3a0 kthread+0xe2/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-50193"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-18T11:15:49Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: wake up all waiters after z_erofs_lzma_head ready\n\nWhen the user mounts the erofs second times, the decompression thread\nmay hung. The problem happens due to a sequence of steps like the\nfollowing:\n\n1) Task A called z_erofs_load_lzma_config which obtain all of the node\n   from the z_erofs_lzma_head.\n\n2) At this time, task B called the z_erofs_lzma_decompress and wanted to\n   get a node. But the z_erofs_lzma_head was empty, the Task B had to\n   sleep.\n\n3) Task A release nodes and push nodes into the z_erofs_lzma_head. But\n   task B was still sleeping.\n\nOne example report when the hung happens:\ntask:kworker/u3:1 state:D stack:14384 pid: 86 ppid: 2 flags:0x00004000\nWorkqueue: erofs_unzipd z_erofs_decompressqueue_work\nCall Trace:\n \u003cTASK\u003e\n __schedule+0x281/0x760\n schedule+0x49/0xb0\n z_erofs_lzma_decompress+0x4bc/0x580\n ? cpu_core_flags+0x10/0x10\n z_erofs_decompress_pcluster+0x49b/0xba0\n ? __update_load_avg_se+0x2b0/0x330\n ? __update_load_avg_se+0x2b0/0x330\n ? update_load_avg+0x5f/0x690\n ? update_load_avg+0x5f/0x690\n ? set_next_entity+0xbd/0x110\n ? _raw_spin_unlock+0xd/0x20\n z_erofs_decompress_queue.isra.0+0x2e/0x50\n z_erofs_decompressqueue_work+0x30/0x60\n process_one_work+0x1d3/0x3a0\n worker_thread+0x45/0x3a0\n ? process_one_work+0x3a0/0x3a0\n kthread+0xe2/0x110\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x22/0x30\n \u003c/TASK\u003e",
  "id": "GHSA-9244-ghq8-mvq4",
  "modified": "2025-11-19T15:31:29Z",
  "published": "2025-06-18T12:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50193"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2478e36ec437a27f8a05bea9e4269a68c554e21f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2df7c4bd7c1d2bc5ece5e9ed19dbd386810c2a65"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/96aa2a6a89618d850ef082e4268007e840c28769"
    }
  ],
  "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.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

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.


Loading…