In the Linux kernel, the following vulnerability has been resolved: usb: gadget: userial: Fix the issue that gsstartio 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->portlock) Crash This causes thread A to access a null pointer (port->portusb is null) when calling the gsfreerequests 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->portusb. 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 dosysopenat2+0x84/0xf0 _arm64sysopenat+0x70/0x9c invokesyscall+0x58/0x114 el0svccommon+0x80/0xe0 doel0svc+0x1c/0x28 el0svc+0x38/0x68