CVE-2026-64528
NoneCVSS
—
EPSS
0.2%
Published
Jul 25, 2026
CISA due date
—
Cloudanix analysis
Some Linux-based devices using a specific Samsung serial-console driver can freeze when serial flow control is triggered, potentially causing outages or loss of management access.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
This vulnerability is a Linux kernel deadlock in the Samsung S3C24xx serial driver. When console flow control is enabled, transmit start/stop paths can call receive enable/disable helper functions while the serial port spinlock is already held. Those helper functions attempt to acquire the same non-recursive spinlock again, causing the CPU execution path to deadlock. The practical technical impact is denial of service for affected systems using this driver and configuration, potentially resulting in a hung serial console, stalled kernel execution path, or broader system unresponsiveness depending on how the serial console is used.
Why it matters to the business
Systems that rely on affected Samsung serial hardware or kernels containing this driver may become unresponsive when the vulnerable console flow-control path is triggered. This is most relevant to embedded Linux devices, appliances, development boards, industrial systems, and products that use Samsung S3C24xx-style serial support. Because there is no known public exploitation and the EPSS score is very low, the immediate internet-scale risk is limited, but affected embedded or operational devices may experience outages, difficult remote recovery, or loss of management-console access if the condition is triggered.
How an attack unfolds
An attacker would need a way to influence or trigger serial-console activity on a system using the affected Samsung serial driver with console flow control enabled. By causing transmit start or stop activity while console flow control is engaged, the kernel enters a code path where the serial framework or an internal TX completion/interrupt handler already holds the serial port lock. The vulnerable receive helper then tries to acquire that same lock again. Because the lock is a spinlock and cannot be recursively acquired, the execution path deadlocks. The result is a denial-of-service condition rather than code execution or privilege escalation. Exploitation is most plausible through local, physical, adjacent, or device-management paths that can interact with the affected serial interface, not as a generic remote network attack.
How to fix it
Apply a Linux kernel update from the relevant distribution, device vendor, SoC vendor, or product maintainer that includes the upstream fix removing the redundant lock acquisition from the Samsung serial receive helper functions. If a vendor kernel is maintained internally, backport the patch that removes the unnecessary uart_port_lock_irqsave() locking from s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable(). If immediate patching is not possible, reduce exposure by disabling console flow control where operationally safe, avoiding use of the affected serial port as a management console, limiting physical or remote access to serial-management interfaces, and monitoring for hangs or watchdog resets on devices using this driver.
How to confirm the fix worked
Confirm whether the running kernel includes the fixed Samsung serial driver code by checking the vendor kernel changelog, package advisory, or source tree for the patch that removes redundant port-lock acquisition in the Samsung serial RX helper functions. On source-based or internally maintained kernels, verify that s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() no longer acquire port->lock internally when called from paths where the serial core already holds the lock. Validate runtime exposure by checking whether the kernel includes or loads the samsung/s3c24xx serial driver and whether console flow control is enabled for the affected serial port. After patching, regression-test serial console TX/RX behavior, flow-control behavior, suspend/resume if applicable, and watchdog stability under serial-console load.
Typical attack path
- Identify a Linux-based system using the Samsung S3C24xx serial driver or a downstream kernel containing the vulnerable code.
- Determine that the serial port is configured as a console or otherwise uses console flow control.
- Gain the ability to interact with or influence the affected serial interface, such as through local device access, exposed management-console access, or a connected peripheral path.
- Trigger transmit start/stop behavior while console flow control is active.
- Cause the vulnerable receive enable/disable helper to attempt to reacquire an already-held serial port spinlock.
- Induce a kernel deadlock, resulting in serial-console failure, stalled kernel execution, or system unresponsiveness.
How to detect it
To determine whether this was already triggered, review kernel logs, serial-console logs, watchdog logs, crash dumps, and persistent system journals around periods of device unresponsiveness. Look for kernel soft lockups, hard lockups, hung tasks, watchdog resets, or the last active stack traces involving the Samsung serial driver functions s3c24xx_serial_stop_tx(), s3c24xx_serial_start_tx(), s3c24xx_serial_rx_enable(), s3c24xx_serial_rx_disable(), s3c24xx_serial_tx_dma_complete(), or s3c24xx_serial_tx_irq(). Because this issue causes a deadlock rather than dropping a payload or creating files, there may be no durable forensic artifact beyond kernel logs, console traces, pstore/ramoops records, crash dumps, or device reset telemetry. Correlate any lockup with serial-console use, flow-control changes, field-service activity, or peripheral activity on the affected UART. There are no known public threat actors or ransomware campaigns associated with this issue based on the provided data.
- s3c24xx_serial_rx_enable
- s3c24xx_serial_rx_disable
- s3c24xx_serial_stop_tx
- s3c24xx_serial_start_tx
- s3c24xx_serial_tx_dma_complete
- s3c24xx_serial_tx_irq
- UPF_CONS_FLOW
- BUG: soft lockup
- BUG: hard lockup
- watchdog: BUG: soft lockup
- NMI watchdog: Watchdog detected hard LOCKUP
- INFO: rcu_sched detected stalls
- rcu: INFO: rcu_preempt detected stalls
- Kernel panic - not syncing: softlockup
- pstore
- ramoops
What your security team should do
- Inventory Linux devices, embedded products, appliances, and custom kernels that include Samsung S3C24xx serial support.
- Prioritize patching for systems where the affected serial driver is used for console, recovery, field service, industrial control, or other operational management functions.
- Obtain a kernel or firmware update from the responsible vendor, or backport the upstream kernel fix into maintained downstream kernels.
- Where patching is delayed, restrict physical and remote access to serial-management interfaces and disable console flow control if operationally acceptable.
- Monitor affected device fleets for unexplained hangs, watchdog resets, serial-console lockups, or kernel soft-lockup messages.
- Include this issue in embedded Linux firmware release validation, especially for products using Samsung ARM SoCs or downstream kernels with the s3c24xx serial driver.
The record
In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|