CVE-2023-52894

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()<br /> <br /> In Google internal bug 265639009 we&amp;#39;ve received an (as yet) unreproducible<br /> crash report from an aarch64 GKI 5.10.149-android13 running device.<br /> <br /> AFAICT the source code is at:<br /> https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10<br /> <br /> The call stack is:<br /> ncm_close() -&gt; ncm_notify() -&gt; ncm_do_notify()<br /> with the crash at:<br /> ncm_do_notify+0x98/0x270<br /> Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)<br /> <br /> Which I believe disassembles to (I don&amp;#39;t know ARM assembly, but it looks sane enough to me...):<br /> <br /> // halfword (16-bit) store presumably to event-&gt;wLength (at offset 6 of struct usb_cdc_notification)<br /> 0B 0D 00 79 strh w11, [x8, #6]<br /> <br /> // word (32-bit) store presumably to req-&gt;Length (at offset 8 of struct usb_request)<br /> 6C 0A 00 B9 str w12, [x19, #8]<br /> <br /> // x10 (NULL) was read here from offset 0 of valid pointer x9<br /> // IMHO we&amp;#39;re reading &amp;#39;cdev-&gt;gadget&amp;#39; and getting NULL<br /> // gadget is indeed at offset 0 of struct usb_composite_dev<br /> 2A 01 40 F9 ldr x10, [x9]<br /> <br /> // loading req-&gt;buf pointer, which is at offset 0 of struct usb_request<br /> 69 02 40 F9 ldr x9, [x19]<br /> <br /> // x10 is null, crash, appears to be attempt to read cdev-&gt;gadget-&gt;max_speed<br /> 4B 5D 40 B9 ldr w11, [x10, #0x5c]<br /> <br /> which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:<br /> <br /> event-&gt;wLength = cpu_to_le16(8);<br /> req-&gt;length = NCM_STATUS_BYTECOUNT;<br /> <br /> /* SPEED_CHANGE data is up/down speeds in bits/sec */<br /> data = req-&gt;buf + sizeof *event;<br /> data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));<br /> <br /> My analysis of registers and NULL ptr deref crash offset<br /> (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)<br /> heavily suggests that the crash is due to &amp;#39;cdev-&gt;gadget&amp;#39; being NULL when executing:<br /> data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));<br /> which calls:<br /> ncm_bitrate(NULL)<br /> which then calls:<br /> gadget_is_superspeed(NULL)<br /> which reads<br /> ((struct usb_gadget *)NULL)-&gt;max_speed<br /> and hits a panic.<br /> <br /> AFAICT, if I&amp;#39;m counting right, the offset of max_speed is indeed 0x5C.<br /> (remember there&amp;#39;s a GKI KABI reservation of 16 bytes in struct work_struct)<br /> <br /> It&amp;#39;s not at all clear to me how this is all supposed to work...<br /> but returning 0 seems much better than panic-ing...