In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
Inthe Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
Inthe Linux kernel,the following vulnerabilityhas been resolved:usb: gadget: f_ncm:fix potential NULLptr deref in ncm_bitrate()In Google internalbug 265639009 we've received an(as yet) unreproduciblecrash report from an aarch64GKI 5.10.149-android13 running device.AFAICTthe source code isat: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stackis: ncm_close() -> ncm_notify() -> ncm_do_notify()withthe crashat: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't knowARM assembly,but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength(at offset 6 of struct usb_cdc_notification) 0B 0D 0079 strh w11, [x8,#6] // word (32-bit) store presumably to req->Length(at offset 8 of struct usb_request) 6C 0A 00B9 str w12, [x19,#8] //x10 (NULL)was read here from offset 0 of valid pointerx9 // IMHO we're reading 'cdev->gadget'and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40F9 ldr x9, [x19] //x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec*/ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registersand NULLptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests thatthe crash isdue to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right,the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It'snot atall clear to mehow this isall supposed to work...butreturning 0 seems much better than panic-ing...The Linux kernelCVE teamhas assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
IntheLinux kernel, thefollowing vulnerability hasbeen resolved:usb: gadget: f_ncm: fixpotential NULL ptrderef in ncm_bitrate()In Google internal bug265639009 we've received an (asyet) unreproduciblecrash report from an aarch64 GKI5.10.149-android13 running device.AFAICT thesource code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with thecrash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARMassembly, butit looks sane enough to me...): //halfword (16-bit) store presumably to event->wLength (atoffset 6 of structusb_cdc_notification) 0B0D 00 79 strh w11, [x8, #6] //word (32-bit) store presumably to req->Length (atoffset 8 of structusb_request) 6C0A 00 B9 str w12, [x19, #8] //x10(NULL) wasread here from offset 0 of valid pointer x9 //IMHO we're reading 'cdev->gadget' andgetting NULL //gadget is indeed at offset 0 of structusb_composite_dev 2A01 40 F9 ldr x10, [x9] //loading req->buf pointer, which is at offset 0 of structusb_request 6902 40 F9 ldr x9,[x19] //x10is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /*SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers andNULL ptrderef crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that thecrash is dueto 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((structusb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, theoffset of max_speed is indeed 0x5C.(remember there's a GKIKABI reservation of 16 bytes in struct work_struct)It's notat allclear to me howthis is allsupposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVEteam hasassigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, thefollowing vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internalbug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICTthe source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() ->ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, butit lookssane enoughto me...): //halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8ofstruct usb_request) 6C 0A 00 B9str w12, [x19, #8] // x10 (NULL) wasread here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' andgetting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 0140 F9 ldr x10, [x9] // loading req->buf pointer,which is at offset 0 of struct usb_request 69 0240 F9 ldr x9, [x19] // x10isnull, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11,[x10, #0x5c]which seems to lineup with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf +sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULLptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavilysuggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedandhits a panic.AFAICT, ifI'm counting right,the offset of max_speed is indeed 0x5C.(remember there's aGKI KABIreservation of 16 bytes in struct work_struct)It's not at allclear to me howthis is all supposedto work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team hasassigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
IntheLinuxkernel,the following vulnerabilityhas been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we'vereceived an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with thecrash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to(I don't know ARM assembly, but it looks sane enough tome...): // halfword(16-bit) storepresumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8,#6] //word (32-bit) storepresumably to req->Length (at offset 8 of struct usb_request) 6C0A 00 B9 str w12, [x19, #8] //x10(NULL) was readhere from offset 0of valid pointer x9 //IMHO we're reading 'cdev->gadget' and getting NULL // gadgetis indeed atoffset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->bufpointer, which is at offset 0 ofstruct usb_request 69 02 40 F9 ldr x9,[x19] // x10is null, crash,appearstobe attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]whichseemsto line up with ncm_do_notify()case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data isup/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crashis due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)whichthen calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, ifI'm counting right,the offset of max_speedis indeed 0x5C.(remember there's a GKI KABI reservation of16 bytesin struct work_struct)It's not at all clear to me how this isall supposed towork...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb:gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's aGKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there'sa GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
Inthe Linuxkernel, the following vulnerability has beenresolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009we've received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13running device.AFAICT the source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to(I don't know ARM assembly, but it looks saneenough to me...): // halfword (16-bit) store presumably toevent->wLength (at offset 6 of structusb_cdc_notification) 0B0D 00 79 strh w11, [x8,#6] // word (32-bit) store presumablyto req->Length (at offset 8 of struct usb_request) 6C0A 00B9 str w12, [x19, #8] // x10 (NULL) wasreadhere from offset0 of valid pointerx9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadgetisindeedat offset 0 of structusb_composite_dev 2A01 40F9 ldr x10, [x9] // loading req->buf pointer, which isat offset 0of structusb_request 69 02 40F9 ldr x9, [x19] // x10 is null, crash,appearsto be attempt to read cdev->gadget->max_speed 4B5D 40B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/downspeeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysisof registers and NULL ptr derefcrash offset (Unableto handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' beingNULL whenexecuting: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed isindeed 0x5C.(remember there's a GKI KABI reservationof 16 bytes in struct work_struct)It's not at all clearto me how this is all supposed to work...but returning 0 seems much better thanpanic-ing...TheLinux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
IntheLinuxkernel,thefollowingvulnerability has been resolved:usb: gadget:f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an(as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICTthe source code is at: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARMassembly, but it looks sane enough to me...): //halfword (16-bit)store presumably to event->wLength (atoffset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11,[x8, #6]// word (32-bit)store presumably to req->Length (atoffset 8 of struct usb_request) 6C 0A 00 B9 str w12,[x19,#8]// x10 (NULL) was read here from offset0 ofvalid pointer x9 // IMHO we'rereading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0ofstructusb_composite_dev 2A01 40 F9 ldr x10,[x9] //loadingreq->buf pointer, which is at offset 0 of structusb_request 69 02 40F9 ldr x9, [x19] //x10 isnull, crash, appears to be attemptto readcdev->gadget->max_speed 4B 5D 40 B9 ldr w11,[x10,#0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE datais up/down speeds in bits/sec */ data = req->buf +sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULLptr deref crash offset (Unableto handle kernel NULLpointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(rememberthere's a GKI KABI reservation of 16 bytes in structwork_struct)It's not at all clear to me how this is allsupposed to work...but returning 0 seems much better than panic-ing...The Linuxkernel CVE teamhas assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we've received an(as yet) unreproduciblecrash report from an aarch64GKI 5.10.149-android13 running device.AFAICTthe source code isat: <ahref= https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 >https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10</a>The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don't know ARM assembly,but it looks sane enough to me...): // halfword (16-bit) storepresumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 0079strh w11, [x8, #6] // word (32-bit)store presumably to req->Length(at offset 8 of struct usb_request) 6C 0A00 B9 str w12,[x19, #8] //x10 (NULL) was read here fromoffset 0 ofvalid pointer x9 // IMHO we're reading'cdev->gadget'and getting NULL //gadget is indeed at offset 0 ofstruct usb_composite_dev 2A 01 40 F9ldr x10, [x9] // loadingreq->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appearsto be attempt toreadcdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec*/ data =req->buf +sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis ofregistersand NULL ptr deref crashoffset (Unableto handle kernel NULLpointer dereference at virtual address 000000000000005c)heavily suggests that the crashis due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)whichthen calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)It's not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...The Linux kernel CVE team has assigned CVE-2023-52894 to this issue.
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (asyet) unreproduciblecrash report from an aarch64 GKI5.10.149-android13 running device.AFAICT thesource code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassemblesto (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 ofstruct usb_cdc_notification) 0B 0D00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C0A00 B9 str w12,[x19, #8] // x10(NULL) was read here from offset 0of valid pointer x9 // IMHO we re reading cdev->gadget andgetting NULL // gadget is indeed at offset0 of structusb_composite_dev 2A 01 40 F9 ldr x10,[x9] // loading req->bufpointer, which isatoffset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10isnull, crash, appears to beattempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]whichseems to line up with ncm_do_notify() caseNCM_NOTIFY_SPEEDcodefragment: event->wLength = cpu_to_le16(8);req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable tohandle kernelNULL pointer dereference at virtual address 000000000000005c)heavily suggests thatthe crashis due to cdev->gadget being NULL whenexecuting: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)whichthen calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, theoffset of max_speed isindeed 0x5C.(remember theres a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which Ibelieve disassembles to (I don tknow ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength =cpu_to_le16(8); req->length =NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data =req->buf +sizeof *event; data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] =cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits apanic.AFAICT, if Imcounting right, the offset of max_speed is indeed 0x5C.(remember there saGKI KABI reservation of 16 bytes in struct work_struct)It snot at all clear to me how this is all supposed to work...but returning 0seems much better than panic-ing...
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don t know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hits a panic.AFAICT, if I m counting right, the offset of max_speed is indeed 0x5C.(remember there s a GKI KABI reservation of 16 bytes in struct work_struct)It s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...
| linux | | https://git.kernel.org/linus/c6ec929595c7443250b2a4faea988c62019d5cd2 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()In Google internal bug 265639009 we ve received an (as yet) unreproduciblecrash report from an aarch64 GKI 5.10.149-android13 running device.AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify()with the crash at: ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)WhichI believe disassembles to (I dont know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset0 of valid pointer x9 // IMHO we re reading cdev->gadget and getting NULL // gadget is indeed at offset0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength= cpu_to_le16(8); req->length= NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data= req->buf+ sizeof *event; data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)heavily suggests that the crash is due to cdev->gadget being NULL when executing: data[0]= cpu_to_le32(ncm_bitrate(cdev->gadget));which calls: ncm_bitrate(NULL)which then calls: gadget_is_superspeed(NULL)which reads ((struct usb_gadget *)NULL)->max_speedand hitsa panic.AFAICT, ifIm counting right, the offset of max_speed is indeed 0x5C.(remember theresa GKI KABI reservation of 16 bytes in struct work_struct)Its not at all clear to me how this is all supposed to work...but returning0 seems much better than panic-ing...
