CVE-2024-56670 — usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer

Affected: Linux

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer

Considering that in some extreme cases, when u_serial driver is accessed by multiple threads, Thread A is executing the open operation and calling the gs_open, Thread B is executing the disconnect operation and calling the gserial_disconnect function,The port->port_usb pointer will be set to NULL.

E.g. Thread A Thread B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) Crash

This causes thread A to access a null pointer (port->port_usb is null) when calling the gs_free_requests function, causing a crash.

If port_usb is NULL, the release request will be skipped as it will be done by gserial_disconnect.

So add a null pointer check to gs_start_io before attempting to access the value of the pointer port->port_usb.

Call trace: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+…

Most recent entries from all

CVE-2024-56670 — usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer