CVE-2022-50344
BaseFortify
Publication date: 2025-09-16
Last updated on: 2025-12-01
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | to 4.9.331 (exc) |
| linux | linux_kernel | From 4.10 (inc) to 4.14.296 (exc) |
| linux | linux_kernel | From 4.15 (inc) to 4.19.262 (exc) |
| linux | linux_kernel | From 4.20 (inc) to 5.4.220 (exc) |
| linux | linux_kernel | From 5.5 (inc) to 5.10.150 (exc) |
| linux | linux_kernel | From 5.11 (inc) to 5.15.75 (exc) |
| linux | linux_kernel | From 5.16 (inc) to 5.19.17 (exc) |
| linux | linux_kernel | From 6.0 (inc) to 6.0.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-476 | The product dereferences a pointer that it expects to be valid but is NULL. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is a null pointer dereference bug in the ext4 filesystem code of the Linux kernel. It occurs in the ext4_write_info function when the filesystem's root pointer (s_root) is set to NULL during unmount operations, but the code still attempts to access it, leading to a null pointer dereference and potential kernel crash. The fix involves changing the code to avoid using the s_root pointer directly by using ext4_journal_start_sb instead.
How can this vulnerability impact me? :
This vulnerability can cause the Linux kernel to crash or panic due to a null pointer dereference when unmounting an ext4 filesystem. This can lead to system instability, denial of service, or data loss if the system becomes unresponsive or crashes unexpectedly.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability manifests as a null pointer dereference in the ext4_write_info function, which may cause kernel crashes or system instability. Detection can involve monitoring kernel logs for messages related to null pointer dereferences or KASAN reports similar to the provided stack trace. You can check the kernel logs using commands like 'dmesg | grep -i ext4' or 'journalctl -k | grep -i ext4' to look for related errors. Additionally, monitoring for system crashes or umount failures may indicate the presence of this issue.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation is to update the Linux kernel to a version that includes the fix for this vulnerability, which avoids using s_root in ext4_journal_start_sb to prevent the null pointer dereference. Until an update is applied, avoid operations that trigger the vulnerable code path, such as unmounting ext4 filesystems under heavy quota or journal activity. Monitoring and limiting such operations can reduce the risk of triggering the bug.