CVE-2025-38262 in Linux
Summary
by MITRE • 07/09/2025
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: uartlite: register uart driver in init
When two instances of uart devices are probing, a concurrency race can occur. If one thread calls uart_register_driver function, which first allocates and assigns memory to 'uart_state' member of uart_driver structure, the other instance can bypass uart driver registration and call ulite_assign. This calls uart_add_one_port, which expects the uart driver to be fully initialized. This leads to a kernel panic due to a null pointer dereference:
[ 8.143581] BUG: kernel NULL pointer dereference, address: 00000000000002b8
[ 8.156982] #PF: supervisor write access in kernel mode
[ 8.156984] #PF: error_code(0x0002) - not-present page
[ 8.156986] PGD 0 P4D 0
... [ 8.180668] RIP: 0010:mutex_lock+0x19/0x30
[ 8.188624] Call Trace:
[ 8.188629] ? __die_body.cold+0x1a/0x1f
[ 8.195260] ? page_fault_oops+0x15c/0x290
[ 8.209183] ? __irq_resolve_mapping+0x47/0x80
[ 8.209187] ? exc_page_fault+0x64/0x140
[ 8.209190] ? asm_exc_page_fault+0x22/0x30
[ 8.209196] ? mutex_lock+0x19/0x30
[ 8.223116] uart_add_one_port+0x60/0x440
[ 8.223122] ? proc_tty_register_driver+0x43/0x50
[ 8.223126] ? tty_register_driver+0x1ca/0x1e0
[ 8.246250] ulite_probe+0x357/0x4b0 [uartlite]
To prevent it, move uart driver registration in to init function. This will ensure that uart_driver is always registered when probe function is called.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 05/03/2026
This vulnerability exists within the Linux kernel's uartlite driver implementation, specifically affecting the serial communication subsystem. The issue manifests as a race condition during device probing when multiple instances of uart devices are being initialized simultaneously. The vulnerability stems from improper synchronization mechanisms during the driver registration process, creating a scenario where the kernel's initialization sequence can become corrupted.
The technical flaw occurs when one thread executing the uart_register_driver function allocates memory and assigns values to the uart_state member of the uart_driver structure, while another thread concurrently calls ulite_assign function. This concurrent execution bypasses proper driver registration protocols, leading to a situation where uart_add_one_port is invoked before the uart_driver structure is fully initialized. The kernel's expectation that the driver structure contains valid references is violated, resulting in a null pointer dereference at memory address 0x00000000000002b8.
The operational impact of this vulnerability is severe, as it can cause immediate system crashes through kernel panic conditions. The null pointer dereference occurs during a critical kernel initialization phase, specifically when mutex_lock is called during uart_add_one_port execution. This prevents the system from properly establishing serial communication capabilities and can lead to complete system instability. The vulnerability affects any system running the Linux kernel with uartlite drivers, particularly those with multiple serial device instances or rapid device probing scenarios.
The root cause aligns with CWE-362, which describes a race condition vulnerability where concurrent threads access shared resources without proper synchronization. This vulnerability also maps to ATT&CK technique T1068, which involves exploiting local privilege escalation opportunities through kernel-level flaws. The fix implemented involves moving the uart driver registration process into the initialization function, ensuring that all driver structures are properly initialized before any probe functions attempt to access them. This approach prevents the race condition by establishing proper ordering and synchronization, eliminating the possibility of concurrent access to uninitialized driver structures. The mitigation strategy ensures that the uart_driver structure is fully populated and registered before any device probing operations can proceed, thereby preventing the null pointer dereference that leads to kernel panic conditions.