{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2022-50193", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2025-06-18T10:57:27.428Z", "datePublished": "2025-06-18T11:03:38.262Z", "dateUpdated": "2025-06-18T11:03:38.262Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2025-06-18T11:03:38.262Z"}, "descriptions": [{"lang": "en", "value": "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 <TASK>\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 </TASK>"}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["fs/erofs/decompressor_lzma.c"], "versions": [{"version": "622ceaddb7649ca328832f50ba1400af778d75fa", "lessThan": "2478e36ec437a27f8a05bea9e4269a68c554e21f", "status": "affected", "versionType": "git"}, {"version": "622ceaddb7649ca328832f50ba1400af778d75fa", "lessThan": "96aa2a6a89618d850ef082e4268007e840c28769", "status": "affected", "versionType": "git"}, {"version": "622ceaddb7649ca328832f50ba1400af778d75fa", "lessThan": "2df7c4bd7c1d2bc5ece5e9ed19dbd386810c2a65", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["fs/erofs/decompressor_lzma.c"], "versions": [{"version": "5.16", "status": "affected"}, {"version": "0", "lessThan": "5.16", "status": "unaffected", "versionType": "semver"}, {"version": "5.18.18", "lessThanOrEqual": "5.18.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.19.2", "lessThanOrEqual": "5.19.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.0", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "cpeApplicability": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "5.16", "versionEndExcluding": "5.18.18"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "5.16", "versionEndExcluding": "5.19.2"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "5.16", "versionEndExcluding": "6.0"}]}]}], "references": [{"url": "https://git.kernel.org/stable/c/2478e36ec437a27f8a05bea9e4269a68c554e21f"}, {"url": "https://git.kernel.org/stable/c/96aa2a6a89618d850ef082e4268007e840c28769"}, {"url": "https://git.kernel.org/stable/c/2df7c4bd7c1d2bc5ece5e9ed19dbd386810c2a65"}], "title": "erofs: wake up all waiters after z_erofs_lzma_head ready", "x_generator": {"engine": "bippy-1.2.0"}}}}

{}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "5B42E453-8837-49D0-A5EF-03F818A6DC11", "versionEndExcluding": "5.18.18", "versionStartIncluding": "5.16", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "A1A2A5A5-4598-4D7E-BA07-4660398D6C8F", "versionEndExcluding": "5.19.2", "versionStartIncluding": "5.19", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "descriptions": [{"lang": "en", "value": "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 <TASK>\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 </TASK>"}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: despierta a todos los que esperan despu\u00e9s de que z_erofs_lzma_head est\u00e9 listo Cuando el usuario monta erofs por segunda vez, el hilo de descompresi\u00f3n puede colgarse. El problema ocurre debido a una secuencia de pasos como la siguiente: 1) La tarea A llam\u00f3 a z_erofs_load_lzma_config que obtiene todos los nodos de z_erofs_lzma_head. 2) En este momento, la tarea B llam\u00f3 a z_erofs_lzma_decompress y quiso obtener un nodo. Pero z_erofs_lzma_head estaba vac\u00edo, la tarea B tuvo que dormir. 3) La tarea A libera nodos y los empuja hacia z_erofs_lzma_head. Pero la tarea B segu\u00eda durmiendo. Un ejemplo de informe cuando se produce el bloqueo: tarea:kworker/u3:1 estado:D pila:14384 pid: 86 ppid: 2 indicadores:0x00004000 Cola de trabajo: erofs_unzipd z_erofs_decompressqueue_work Seguimiento de llamadas: __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 "}], "id": "CVE-2022-50193", "lastModified": "2025-11-19T12:49:05.800", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "[email protected]", "type": "Primary"}]}, "published": "2025-06-18T11:15:49.920", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/2478e36ec437a27f8a05bea9e4269a68c554e21f"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/2df7c4bd7c1d2bc5ece5e9ed19dbd386810c2a65"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/96aa2a6a89618d850ef082e4268007e840c28769"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "NVD-CWE-noinfo"}], "source": "[email protected]", "type": "Primary"}]}

{"bugzilla": {"description": "kernel: erofs: wake up all waiters after z_erofs_lzma_head ready", "id": "2373436", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2373436"}, "csaw": false, "cvss3": {"cvss3_base_score": "7.0", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", "status": "draft"}, "details": ["In the Linux kernel, the following vulnerability has been resolved:\nerofs: wake up all waiters after z_erofs_lzma_head ready\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:\n1) Task A called z_erofs_load_lzma_config which obtain all of the node\nfrom the z_erofs_lzma_head.\n2) At this time, task B called the z_erofs_lzma_decompress and wanted to\nget a node. But the z_erofs_lzma_head was empty, the Task B had to\nsleep.\n3) Task A release nodes and push nodes into the z_erofs_lzma_head. But\ntask B was still sleeping.\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<TASK>\n__schedule+0x281/0x760\nschedule+0x49/0xb0\nz_erofs_lzma_decompress+0x4bc/0x580\n? cpu_core_flags+0x10/0x10\nz_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\nz_erofs_decompress_queue.isra.0+0x2e/0x50\nz_erofs_decompressqueue_work+0x30/0x60\nprocess_one_work+0x1d3/0x3a0\nworker_thread+0x45/0x3a0\n? process_one_work+0x3a0/0x3a0\nkthread+0xe2/0x110\n? kthread_complete_and_exit+0x20/0x20\nret_from_fork+0x22/0x30\n</TASK>"], "name": "CVE-2022-50193", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:10", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 10"}, {"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2025-06-18T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2022-50193\nhttps://nvd.nist.gov/vuln/detail/CVE-2022-50193\nhttps://lore.kernel.org/linux-cve-announce/2025061837-CVE-2022-50193-84a0@gregkh/T"], "threat_severity": "Moderate"}