CVSS: -EPSS: 0%CPEs: 1EXPL: 0CVE-2023-52895 – io_uring/poll: don't reissue in case of poll race on multishot request
https://notcve.org/view.php?id=CVE-2023-52895
In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: don't reissue in case of poll race on multishot request A previous commit fixed a poll race that can occur, but it's only applicable for multishot requests. For a multishot request, we can safely ignore a spurious wakeup, as we never leave the waitqueue to begin with. A blunt reissue of a multishot armed request can cause us to leak a buffer, if they are ring provided. While this seems like a bug in itself, it's not really defined behavior to reissue a multishot request directly. It's less efficient to do so as well, and not required to rearm anything like it is for singleshot poll requests. • https://git.kernel.org/stable/c/c06015ebc4367be38904b88582e13cc079672075 https://git.kernel.org/stable/c/36fc7317cdb16cfeae0f879916995037bb615ac4 https://git.kernel.org/stable/c/8caa03f10bf92cb8657408a6ece6a8a73f96ce13 •
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: 6EXPL: 0CVE-2022-48899 – drm/virtio: Fix GEM handle creation UAF
https://notcve.org/view.php?id=CVE-2022-48899
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix GEM handle creation UAF Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done *after* we are done dereferencing the object. • https://git.kernel.org/stable/c/62fb7a5e10962ac6ae2a2d2dbd3aedcb2a3e3257 https://git.kernel.org/stable/c/19ec87d06acfab2313ee82b2a689bf0c154e57ea https://git.kernel.org/stable/c/d01d6d2b06c0d8390adf8f3ba08aa60b5642ef73 https://git.kernel.org/stable/c/68bcd063857075d2f9edfed6024387ac377923e2 https://git.kernel.org/stable/c/011ecdbcd520c90c344b872ca6b4821f7783b2f8 https://git.kernel.org/stable/c/adc48e5e408afbb01d261bd303fd9fbbbaa3e317 https://git.kernel.org/stable/c/52531258318ed59a2dc5a43df2eaf0eb1d65438e •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48898 – drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer
https://notcve.org/view.php?id=CVE-2022-48898
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer There are 3 possible interrupt sources are handled by DP controller, HPDstatus, Controller state changes and Aux read/write transaction. At every irq, DP controller have to check isr status of every interrupt sources and service the interrupt if its isr status bits shows interrupts are pending. There is potential race condition may happen at current aux isr handler implementation since it is always complete dp_aux_cmd_fifo_tx() even irq is not for aux read or write transaction. This may cause aux read transaction return premature if host aux data read is in the middle of waiting for sink to complete transferring data to host while irq happen. This will cause host's receiving buffer contains unexpected data. This patch fixes this problem by checking aux isr and return immediately at aux isr handler if there are no any isr status bits set. Current there is a bug report regrading eDP edid corruption happen during system booting up. After lengthy debugging to found that VIDEO_READY interrupt was continuously firing during system booting up which cause dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data from aux hardware buffer which is not yet contains complete data transfer from sink. • https://git.kernel.org/stable/c/c943b4948b5848fc0e07f875edbd35a973879e22 https://git.kernel.org/stable/c/785607e5e6fb52caf141e4580de40405565f04f1 https://git.kernel.org/stable/c/984ad875db804948c86ca9e1c2e784ae8252715a https://git.kernel.org/stable/c/b7dcbca46db3c77fdb02c2a9d6239e5aa3b06a59 https://git.kernel.org/stable/c/1cba0d150fa102439114a91b3e215909efc9f169 •