CVE-2022-50082
BaseFortify
Publication date: 2025-06-18
Last updated on: 2025-11-18
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-362 | The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is a race condition in the ext4 filesystem code of the Linux kernel, specifically between the bmap and write operations. It causes a warning and potential bug when ext4_iomap_begin is called concurrently with write operations, due to improper locking of the inode. The issue is triggered when inline data handling conflicts occur, which can lead to a kernel warning or bug. The fix involves holding the inode lock in ext4_bmap to prevent this race condition.
How can this vulnerability impact me? :
This vulnerability can cause kernel warnings and potentially trigger bugs in the Linux kernel's ext4 filesystem, which may lead to system instability or crashes during file write operations. It affects the reliability of the filesystem and could disrupt normal system operation.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring the system logs for the specific warning message related to ext4_iomap_begin. You can check the kernel logs for the warning using the command: dmesg | grep ext4_iomap_begin. Additionally, monitoring for the warning message 'WARNING: CPU: ... ext4_iomap_begin' in /var/log/kern.log or /var/log/messages can help identify if the issue is occurring.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation is to update the Linux kernel to a version where this issue is fixed, as the vulnerability is resolved by holding the inode lock in ext4_bmap. Until the update is applied, monitoring for the warning messages and avoiding workloads that trigger heavy ext4 inline data writes may reduce the risk.