CVE-2024-56670

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

usb: gadget: userial: Fix the issue that gsstart_io crashed due to accessing null pointer

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

E.g. Thread A Thread B gsopen() gadgetunbinddriver() gsstartio() compositedisconnect() gsstartrx() gserialdisconnect() ... ... spinunlock(&port->portlock) status = usbepqueue() spinlock(&port->portlock) spinlock(&port->portlock) port->portusb = NULL gsfreerequests(port->portusb->in) spinunlock(&port->port_lock) Crash

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

If portusb is NULL, the release request will be skipped as it will be done by gserialdisconnect.

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

Call trace: gsstartio+0x164/0x25c gsopen+0x108/0x13c ttyopen+0x314/0x638 chrdevopen+0x1b8/0x258 dodentryopen+0x2c4/0x700 vfsopen+0x2c/0x3c pathopenat+0xa64/0xc60 dofilpopen+0xb8/0x164 dosys_openat2+0x84/0xf0 __arm64sysopenat+0x70/0x9c invokesyscall+0x58/0x114 el0svccommon+0x80/0xe0 doel0svc+0x1c/0x28 el0svc+0x38/0x68