CVE-2024-26600

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

phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP

If the external phy working together with phy-omap-usb2 does not implement send_srp(), we may still attempt to call it. This can happen on an idle Ethernet gadget triggering a wakeup for example:

configfs-gadget.g1 gadget.0: ECM Suspend configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup ... Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute ... PC is at 0x0 LR is at musbgadgetwakeup+0x1d4/0x254 [musbhdrc] ... musbgadgetwakeup [musbhdrc] from usbgadgetwakeup+0x1c/0x3c [udccore] usbgadgetwakeup [udccore] from ethstartxmit+0x3b0/0x3d4 [uether] ethstartxmit [uether] from devhardstartxmit+0x94/0x24c devhardstartxmit from schdirectxmit+0x104/0x2e4 schdirectxmit from __devqueuexmit+0x334/0xd88 __devqueuexmit from arpsolicit+0xf0/0x268 arpsolicit from neighprobe+0x54/0x7c neighprobe from __neigheventsend+0x22c/0x47c __neigheventsend from neighresolveoutput+0x14c/0x1c0 neighresolveoutput from ipfinishoutput2+0x1c8/0x628 ipfinishoutput2 from ipsendskb+0x40/0xd8 ipsendskb from udpsendskb+0x124/0x340 udpsendskb from udpsendmsg+0x780/0x984 udpsendmsg from __sys_sendto+0xd8/0x158 _syssendto from retfastsyscall+0x0/0x58

Let's fix the issue by checking for sendsrp() and setvbus() before calling them. For USB peripheral only cases these both could be NULL.