CVE-2023-53656
BaseFortify
Publication date: 2025-10-07
Last updated on: 2026-02-03
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | From 6.4 (inc) to 6.4.4 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability occurs in the Linux kernel's hisi driver for performance monitoring. When a CPU is going to be taken offline (teardown), the driver attempts to migrate the performance context to another CPU. However, due to timing issues, the migration may mistakenly target the CPU that is being taken offline because the system's CPU online mask has not yet been updated. This leads to a call trace error and potential malfunction. The fix involves using the function cpumask_any_but() to correctly select an active CPU that is not being taken offline for migrating the performance context.
How can this vulnerability impact me? :
This vulnerability can cause system instability or crashes related to performance monitoring on affected Linux systems using the hisi driver. Specifically, it may lead to errors during CPU teardown operations, potentially impacting system reliability and performance monitoring accuracy.
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 specific kernel call traces related to the hisi_pcie_pmu driver during CPU teardown. Look for messages similar to the provided call trace involving functions like __switch_to, __schedule, mutex_lock, perf_pmu_migrate_context, and hisi_pcie_pmu_offline_cpu. Commands such as 'dmesg | grep -i hisi_pcie_pmu' or 'journalctl -k | grep -i hisi_pcie_pmu' can help identify these traces.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves updating the Linux kernel to a version where this issue is fixed. The fix involves changing the driver to use the function cpumask_any_but() to correctly select an active CPU during perf context migration, avoiding migration to a CPU that is going to teardown. Until the update is applied, monitoring for the issue and avoiding CPU teardown operations that trigger this condition may help reduce risk.