CVE-2023-53048

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

usb: typec: tcpm: fix warning when handle discover_identity message

Since both source and sink device can send discover_identity message in PD3, kernel may dump below warning:

------------[ cut here ]------------ WARNING: CPU: 0 PID: 169 at drivers/usb/typec/tcpm/tcpm.c:1446 tcpmqueuevdm+0xe0/0xf0 Modules linked in: CPU: 0 PID: 169 Comm: 1-0050 Not tainted 6.1.1-00038-g6a3c36cf1da2-dirty #567 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : tcpmqueuevdm+0xe0/0xf0 lr : tcpmqueuevdm+0x2c/0xf0 sp : ffff80000c19bcd0 x29: ffff80000c19bcd0 x28: 0000000000000001 x27: ffff0000d11c8ab8 x26: ffff0000d11cc000 x25: 0000000000000000 x24: 00000000ff008081 x23: 0000000000000001 x22: 00000000ff00a081 x21: ffff80000c19bdbc x20: 0000000000000000 x19: ffff0000d11c8080 x18: ffffffffffffffff x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000d716f580 x14: 0000000000000001 x13: ffff0000d716f507 x12: 0000000000000001 x11: 0000000000000000 x10: 0000000000000020 x9 : 00000000000ee098 x8 : 00000000ffffffff x7 : 000000000000001c x6 : ffff0000d716f580 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff80000c19bdbc x1 : 00000000ff00a081 x0 : 0000000000000004 Call trace: tcpmqueuevdm+0xe0/0xf0 tcpmpdrxhandler+0x340/0x1ab0 kthreadworkerfn+0xcc/0x18c kthread+0x10c/0x110 retfrom_fork+0x10/0x20 ---[ end trace 0000000000000000 ]---

Below sequences may trigger this warning:

tcpmsenddiscoverwork(work) tcpmsendvdm(port, USBSIDPD, CMDDISCOVERIDENT, NULL, 0); tcpmqueuevdm(port, header, data, count); port->vdmstate = VDMSTATEREADY;

vdmstatemachinework(work); <-- received discoveridentity from partner vdmrunstatemachine(port); port->vdmstate = VDMSTATESENDMESSAGE; modvdmdelayedwork(port, x);

tcpmpdrxhandler(work); tcpmpddatarequest(port, msg); tcpmhandlevdmrequest(port, msg->payload, cnt); tcpmqueuevdm(port, response[0], &response[1], rlen - 1); --> WARNON(port->vdmstate > VDMSTATE_DONE);

For this case, the state machine could still send out discover identity message later if we skip current discoveridentity message. So we should handle the received message firstly and override the pending discoveridentity message without warning in this case. Then, a delayed senddiscover work will send discoveridentity message again.