CVE-2025-39724
BaseFortify
Publication date: 2025-09-05
Last updated on: 2025-11-03
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | 6.1.153-1 |
| linux | linux_kernel | 5.10.244-1 |
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 serial driver (serial 8250). When a specific parameter (PSLVERR_RESP_EN) is set, the device generates an error if it tries to read from an empty receive buffer while the FIFO is enabled. Due to a race condition involving multiple CPUs accessing the UART simultaneously, the kernel can panic because of improper locking around certain serial port operations. The fix involves adding a lock to prevent concurrent access that leads to this panic.
How can this vulnerability impact me? :
This vulnerability can cause the Linux kernel to panic (crash) when the serial port driver encounters a race condition during UART access. This can lead to system instability, unexpected reboots, or denial of service, especially on systems relying on serial communication.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for kernel panic messages related to the serial8250 driver, specifically looking for panic backtraces mentioning dw8250_serial_in32, serial8250_do_startup, or console_on_rootfs. You can check the system logs using commands like 'dmesg | grep -i serial8250' or 'journalctl -k | grep -i serial8250' to identify such panic messages.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, update the Linux kernel to a version where the fix is applied. The fix involves putting serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to prevent the panic caused by concurrent UART access. Until the update is applied, avoid workloads or operations that trigger concurrent UART access that could lead to this panic.