Hi Greg and Jiri
On Fri, Mar 8, 2024 at 7:47 PM Kuen-Han Tsai khtsai@google.com wrote:
On Sun, Jan 28, 2024 at 9:29 AM Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Jan 18, 2024 at 10:27:54AM +0100, Jiri Slaby wrote:
On 16. 01. 24, 15:16, Kuen-Han Tsai wrote:
Commit ffd603f21423 ("usb: gadget: u_serial: Add null pointer check in gs_start_io") adds null pointer checks to gs_start_io(), but it doesn't fully fix the potential null pointer dereference issue. While gserial_connect() calls gs_start_io() with port_lock held, gs_start_rx() and gs_start_tx() release the lock during endpoint request submission. This creates a window where gs_close() could set port->port_tty to NULL, leading to a dereference when the lock is reacquired.
This patch adds a null pointer check for port->port_tty after RX/TX submission, and removes the initial null pointer check in gs_start_io() since the caller must hold port_lock and guarantee non-null values for port_usb and port_tty.
Or you switch to tty_port refcounting and need not fiddling with this at all ;).
I agree, Kuen-Han, why not do that instead?
The u_serial driver has already maintained the usage count of a TTY structure for open and close. While the driver tracks the usage count via open/close, it doesn't fully eliminate race conditions. Below are two potential scenarios:
Case 1 (Observed):
- gs_open() sets usage count to 1.
- gserial_connect(), gs_start_io(), and gs_start_rx() execute in
sequence (lock held). 3. Lock released, usb_ep_queue() called. 4. In parallel, gs_close() executes, sees count of 1, clears TTY, releases lock. 5. Original thread resumes in gs_start_rx(), potentially leading to kernel panic on an invalid TTY.
The same issue happens in the f_acm function.
[ 369.926837][ T9731] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001f8 [ 369.930098][ T9731] Call trace: [ 369.930108][ T9731] tty_wakeup+0x28/0x160 [ 369.930124][ T9731] gs_start_io+0x128/0x214 [ 369.930136][ T9731] gserial_connect+0xb8/0x158 [ 369.930150][ T9731] acm_set_alt+0xf8/0x118 [ 369.930162][ T9731] set_config+0x258/0x3c0 [ 369.930179][ T9731] composite_setup+0x484/0x984 [ 369.930193][ T9731] android_setup+0x13c/0x24c [ 369.930206][ T9731] dwc3_ep0_interrupt+0x8c4/0x122c [ 369.930224][ T9731] dwc3_thread_interrupt+0xa4/0x1918 [ 369.930238][ T9731] irq_thread_fn+0x44/0xa4 [ 369.930260][ T9731] irq_thread+0x2a8/0x588 [ 369.930272][ T9731] kthread+0x1d0/0x23c [ 369.930289][ T9731] ret_from_fork+0x10/0x20 [ 369.930314][ T9731] Code: d5384108 aa0003f3 f9431d08 f81f83a8 (f940fc08)
Since both gserial_connect() and gs_open() initiate gs_start_io(), there's a brief window where gs_start_rx() releases a spinlock for USB submission. If gs_close() executes during this window, it could acquire the lock and clear the TTY structure prematurely. This happens because the lock is released and the usage count remains 1, making it appear like a valid final reference, even though gs_start_io() is still in progress.
The f_acm function invokes gserial_connect while configuring the altsetting. A similar issue arises when the TTY file node is already opened but closed when the gs_start_io function is executing. The current code includes a spinlock and the usage_count is 1; however, the problem persists, suggesting that the existing spinlock and usage_count are ineffective in preventing the issue. A straightforward solution is to double-check the TTY status before calling the tty_wakeup function.
My only solution so far is to recheck the TTY structure after gs_start_rx() or gs_start_tx(). I would greatly appreciate your insights on how to address this race condition effectively.
I'd like to get your perspective on this issue. Do you have any ideas on how we can move this solution forward?
Regards, Kuen-Han