Hi Prashanth:
>> Added null pointer check to avoid system crash.
>> Still didn't update the commit text with reason for null pointer crash.
>Please mention about the race between gser_disconnect and read/write complete callbacks, and how the port can become Null.
>> usb_gadget_probe_driver+0xa8/0x1dc
>> gadget_dev_desc_UDC_store+0x13c/0x188
>> configfs_write_iter+0x160/0x1f4
>> vfs_write+0x2d0/0x40c
>> ksys_write+0x7c/0xf0
>> __arm64_sys_write+0x20/0x30
>> invoke_syscall+0x60/0x150
>> el0_svc_common+0x8c/0xf8
>> do_el0_svc+0x28/0xa0
>> el0_svc+0x24/0x84
>> el0t_64_sync_handler+0x88/0xec
>> el0t_64_sync+0x1b4/0x1b8
>> Code: aa1f03e1 aa1303e0 52800022 2a0103e8 (88e87e62) ---[ end trace
>> 938847327a739172 ]--- Kernel panic - not syncing: Oops: Fatal
>> exception
>You can also add the Fixes tag and CC stable kernel, so that it can be backported to older kernels (such as 5.15) also.
usb: gadget: u_serial: Add null pointer check in gs_read_complete & gs_write_complete
Considering that in some extreme cases, when the unbind operation
is being executed, gserial_disconnect has already cleared gser->ioport,
and the controller has not stopped & pullup 0, sys.usb.config is reset
and the bind operation will be re-executed, calling gs_read_complete,
which will result in accessing gser->iport, resulting in a null pointer
dereference. Add a null pointer check to prevent this situation.
Added a static spinlock to prevent gser->ioport from becoming
null after the newly added check.
Fixes: c1dca56 ("usb gadget: split out serial core")
Cc: stable <stable@xxxxxxxxxx>
See if this description is feasible?
Thanks
