CVE-2023-53167
BaseFortify
Publication date: 2025-09-15
Last updated on: 2025-11-24
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) |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
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 in the Linux kernel's tracing subsystem, specifically in the function 'tracing_err_log_open'. When a file is opened with only write permissions, the function fails to call 'seq_open', leaving 'file->private_data' as null. If a 'lseek' operation is then performed on this file, the kernel tries to dereference this null pointer, causing a kernel panic (system crash).
How can this vulnerability impact me? :
The impact of this vulnerability is a kernel panic, which causes the system to crash and become unresponsive. However, since writing to the affected node requires root privileges, the security impact is very limited. An attacker would need root access to exploit this issue to cause a denial of service by crashing the kernel.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by attempting to open the tracefs node /sys/kernel/tracing/error_log with write permissions and then performing an lseek operation on it. A kernel panic or NULL pointer dereference in the kernel logs would indicate the presence of the vulnerability. Since writing to this node requires root privileges, detection commands must be run as root. Example commands to test could include: 1) echo some data > /sys/kernel/tracing/error_log (to open with write permissions), 2) then using a tool or script to perform an lseek syscall on the opened file descriptor. Monitoring kernel logs (e.g., dmesg) for panic messages referencing seq_lseek or mutex_lock after these operations can help detect the issue.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include avoiding writing to the /sys/kernel/tracing/error_log node until the kernel is patched, as writing requires root privileges and triggers the vulnerability. Applying the vendor-provided kernel update or patch that fixes the tracing_err_log_open() function to properly call seq_open when opened with write permissions will resolve the issue. Until then, restrict root access to prevent exploitation and monitor for kernel panics related to this vulnerability.