CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52899 – Add exception protection processing for vd in axi_chan_handle_err function
https://notcve.org/view.php?id=CVE-2023-52899
In the Linux kernel, the following vulnerability has been resolved: Add exception protection processing for vd in axi_chan_handle_err function Since there is no protection for vd, a kernel panic will be triggered here in exceptional cases. You can refer to the processing of axi_chan_block_xfer_complete function The triggered kernel panic is as follows: [ 67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 67.848447] Mem abort info: [ 67.848449] ESR = 0x96000004 [ 67.848451] EC = 0x25: DABT (current EL), IL = 32 bits [ 67.848454] SET = 0, FnV = 0 [ 67.848456] EA = 0, S1PTW = 0 [ 67.848458] Data abort info: [ 67.848460] ISV = 0, ISS = 0x00000004 [ 67.848462] CM = 0, WnR = 0 [ 67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000 [ 67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000 [ 67.848472] Internal error: Oops: 96000004 [#1] SMP [ 67.848475] Modules linked in: dmatest [ 67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11 [ 67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--) [ 67.848487] pc : axi_chan_handle_err+0xc4/0x230 [ 67.848491] lr : axi_chan_handle_err+0x30/0x230 [ 67.848493] sp : ffff0803fe55ae50 [ 67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200 [ 67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080 [ 67.848504] x25: ffff800010d33880 x24: ffff80001139d850 [ 67.848508] x23: ffff0800c097c168 x22: 0000000000000000 [ 67.848512] x21: 0000000000000080 x20: 0000000000002000 [ 67.848517] x19: ffff0800c097c080 x18: 0000000000000000 [ 67.848521] x17: 0000000000000000 x16: 0000000000000000 [ 67.848525] x15: 0000000000000000 x14: 0000000000000000 [ 67.848529] x13: 0000000000000000 x12: 0000000000000040 [ 67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a [ 67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270 [ 67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0 [ 67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480 [ 67.848550] x3 : dead000000000100 x2 : dead000000000122 [ 67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168 [ 67.848559] Call trace: [ 67.848562] axi_chan_handle_err+0xc4/0x230 [ 67.848566] dw_axi_dma_interrupt+0xf4/0x590 [ 67.848569] __handle_irq_event_percpu+0x60/0x220 [ 67.848573] handle_irq_event+0x64/0x120 [ 67.848576] handle_fasteoi_irq+0xc4/0x220 [ 67.848580] __handle_domain_irq+0x80/0xe0 [ 67.848583] gic_handle_irq+0xc0/0x138 [ 67.848585] el1_irq+0xc8/0x180 [ 67.848588] arch_cpu_idle+0x14/0x2c [ 67.848591] default_idle_call+0x40/0x16c [ 67.848594] do_idle+0x1f0/0x250 [ 67.848597] cpu_startup_entry+0x2c/0x60 [ 67.848600] rest_init+0xc0/0xcc [ 67.848603] arch_call_rest_init+0x14/0x1c [ 67.848606] start_kernel+0x4cc/0x500 [ 67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1) [ 67.848613] ---[ end trace 585a97036f88203a ]--- • https://git.kernel.org/stable/c/f534dc438828cc3f1f8c6895b8bdfbef079521fb https://git.kernel.org/stable/c/53dd833fd0a2d8f0118d01ea063a70652689d31e https://git.kernel.org/stable/c/20d0a6d17e85a8a816a64fa7d7cae616f1617833 https://git.kernel.org/stable/c/5054d001ffaf76155637c5e5b922c11016cd6a5d https://git.kernel.org/stable/c/51a7ad5b60efac65691729d10745c28fa1016b96 https://git.kernel.org/stable/c/57054fe516d59d03a7bcf1888e82479ccc244f87 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52898 – xhci: Fix null pointer dereference when host dies
https://notcve.org/view.php?id=CVE-2023-52898
In the Linux kernel, the following vulnerability has been resolved: xhci: Fix null pointer dereference when host dies Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race and cause null pointer dereference when host suddenly dies. Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id] virt device at the same time that xhci_kill_endpoint_urbs() tries to loop through all the device's endpoints, checking if there are any cancelled urbs left to give back. hold the xhci spinlock while freeing the virt device • https://git.kernel.org/stable/c/6fac4b5cecb3928a0a81069aaa815a2edc8dd5a1 https://git.kernel.org/stable/c/133b902378e4acbd824c29dd0d48570ad596e368 https://git.kernel.org/stable/c/081105213ff6f661c114781d469233c7d0e09c2e https://git.kernel.org/stable/c/c462ac871f49753eca86bb960f573b993976a5ea https://git.kernel.org/stable/c/ea2ee5e9991caf74e0604f994c1831a5867055b2 https://git.kernel.org/stable/c/a2bc47c43e70cf904b1af49f76d572326c08bca7 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52894 – usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()
https://notcve.org/view.php?id=CVE-2023-52894
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) unreproducible crash 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.10 The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify() with the crash at: ncm_do_notify+0x98/0x270 Code: 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_speed and 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... • https://git.kernel.org/stable/c/fef6b29671b66dfb71f17e337c1ad14b5a2cedae https://git.kernel.org/stable/c/63d161f29cd39c050e8873aa36e0c9fc013bb763 https://git.kernel.org/stable/c/a21da7f7aae618c785f7e4a275d43c06dc8412b6 https://git.kernel.org/stable/c/e92c70059178da751e5af7de02384b7dfadb5ec7 https://git.kernel.org/stable/c/a69c8dfb85b44be9cc223be07d35cc3a9baefbea https://git.kernel.org/stable/c/09e4507ec8ef2d44da6ba4092b8ee2d81f216497 https://git.kernel.org/stable/c/c6ec929595c7443250b2a4faea988c62019d5cd2 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52893 – gsmi: fix null-deref in gsmi_get_variable
https://notcve.org/view.php?id=CVE-2023-52893
In the Linux kernel, the following vulnerability has been resolved: gsmi: fix null-deref in gsmi_get_variable We can get EFI variables without fetching the attribute, so we must allow for that in gsmi. commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi. • https://git.kernel.org/stable/c/74c5b31c6618f01079212332b2e5f6c42f2d6307 https://git.kernel.org/stable/c/ee5763ef829bd923033510de6d1df7c73f085e4b https://git.kernel.org/stable/c/32313c11bdc8a02c577abaf865be3664ab30410a https://git.kernel.org/stable/c/ffef77794fb5f1245c3249b86342bad2299accb5 https://git.kernel.org/stable/c/ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd https://git.kernel.org/stable/c/eb0421d90f916dffe96b4c049ddf01c0c50620d2 https://git.kernel.org/stable/c/6646d769fdb0ce4318ef9afd127f8526d1ca8393 https://git.kernel.org/stable/c/a769b05eeed7accc4019a1ed9799dd720 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48893 – drm/i915/gt: Cleanup partial engine discovery failures
https://notcve.org/view.php?id=CVE-2022-48893
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Cleanup partial engine discovery failures If we abort driver initialisation in the middle of gt/engine discovery, some engines will be fully setup and some not. Those incompletely setup engines only have 'engine->release == NULL' and so will leak any of the common objects allocated. v2: - Drop the destroy_pinned_context() helper for now. It's not really worth it with just a single callsite at the moment. (Janusz) • https://git.kernel.org/stable/c/5c855bcc730656c4b7d30aaddcd0eafc7003e112 https://git.kernel.org/stable/c/78a033433a5ae4fee85511ee075bc9a48312c79e •