CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52474 – IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests
https://notcve.org/view.php?id=CVE-2023-52474
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests hfi1 user SDMA request processing has two bugs that can cause data corruption for user SDMA requests that have multiple payload iovecs where an iovec other than the tail iovec does not run up to the page boundary for the buffer pointed to by that iovec.a Here are the specific bugs: 1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len. Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec to the packet, even if some of those bytes are past iovec->iov.iov_len and are thus not intended to be in the packet. 2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the next iovec in user_sdma_request->iovs when the current iovec is not PAGE_SIZE and does not contain enough data to complete the packet. The transmitted packet will contain the wrong data from the iovec pages. This has not been an issue with SDMA packets from hfi1 Verbs or PSM2 because they only produce iovecs that end short of PAGE_SIZE as the tail iovec of an SDMA request. Fixing these bugs exposes other bugs with the SDMA pin cache (struct mmu_rb_handler) that get in way of supporting user SDMA requests with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So this commit fixes those issues as well. Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec payload user SDMA requests can hit: 1. Overlapping memory ranges in mmu_rb_handler will result in duplicate pinnings. 2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node), the mmu_rb code (1) removes the existing entry under a lock, (2) releases that lock, pins the new pages, (3) then reacquires the lock to insert the extended mmu_rb_node. If someone else comes in and inserts an overlapping entry between (2) and (3), insert in (3) will fail. The failure path code in this case unpins _all_ pages in either the original mmu_rb_node or the new mmu_rb_node that was inserted between (2) and (3). 3. • https://git.kernel.org/stable/c/7724105686e718ac476a6ad3304fea2fbcfcffde https://git.kernel.org/stable/c/9c4c6512d7330b743c4ffd18bd999a86ca26db0d https://git.kernel.org/stable/c/a2bd706ab63509793b5cd5065e685b7ef5cba678 https://git.kernel.org/stable/c/dce59b5443700fbd0d2433ec6e4d4cf063448844 https://git.kernel.org/stable/c/c76cb8f4bdf26d04cfa5485a93ce297dba5e6a80 https://git.kernel.org/stable/c/7e6010f79b58f45b204cf18aa58f4b73c3f30adc https://git.kernel.org/stable/c/00cbce5cbf88459cd1aa1d60d0f1df15477df127 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-46906 – HID: usbhid: fix info leak in hid_submit_ctrl
https://notcve.org/view.php?id=CVE-2021-46906
In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: fix info leak in hid_submit_ctrl In hid_submit_ctrl(), the way of calculating the report length doesn't take into account that report->size can be zero. When running the syzkaller reproducer, a report of size 0 causes hid_submit_ctrl) to calculate transfer_buffer_length as 16384. When this urb is passed to the usb core layer, KMSAN reports an info leak of 16384 bytes. To fix this, first modify hid_report_len() to account for the zero report size case by using DIV_ROUND_UP for the division. Then, call it from hid_submit_ctrl(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: usbhid: corrige fuga de información en hid_submit_ctrl En hid_submit_ctrl(), la forma de calcular la longitud del informe no tiene en cuenta que el tamaño del informe->puede ser cero. • https://git.kernel.org/stable/c/c5d3c142f2d57d40c55e65d5622d319125a45366 https://git.kernel.org/stable/c/41b1e71a2c57366b08dcca1a28b0d45ca69429ce https://git.kernel.org/stable/c/8c064eece9a51856f3f275104520c7e3017fc5c0 https://git.kernel.org/stable/c/0e280502be1b003c3483ae03fc60dea554fcfa82 https://git.kernel.org/stable/c/7f5a4b24cdbd7372770a02f23e347d7d9a9ac8f1 https://git.kernel.org/stable/c/b1e3596416d74ce95cc0b7b38472329a3818f8a9 https://git.kernel.org/stable/c/21883bff0fd854e07429a773ff18f1e9658f50e8 https://git.kernel.org/stable/c/6be388f4a35d2ce5ef7dbf635a8964a5d • CWE-668: Exposure of Resource to Wrong Sphere •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2020-36775 – f2fs: fix to avoid potential deadlock
https://notcve.org/view.php?id=CVE-2020-36775
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid potential deadlock Using f2fs_trylock_op() in f2fs_write_compressed_pages() to avoid potential deadlock like we did in f2fs_write_single_data_page(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar un posible interbloqueo Usando f2fs_trylock_op() en f2fs_write_compressed_pages() para evitar un posible interbloqueo como lo hicimos en f2fs_write_single_data_page(). • https://git.kernel.org/stable/c/0478ccdc8ea016de1ebaf6fe6da0275c2b258c5b https://git.kernel.org/stable/c/8e8542437bb4070423c9754d5ba270ffdbae8c8d https://git.kernel.org/stable/c/df77fbd8c5b222c680444801ffd20e8bbc90a56e • CWE-667: Improper Locking •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2019-25162 – i2c: Fix a potential use after free
https://notcve.org/view.php?id=CVE-2019-25162
In the Linux kernel, the following vulnerability has been resolved: i2c: Fix a potential use after free Free the adap structure only after we are done using it. This patch just moves the put_device() down a bit to avoid the use after free. [wsa: added comment to the code, added Fixes tag] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: corrige un use after free que libera la estructura adap solo después de que hayamos terminado de usarla. Este parche simplemente mueve put_device() un poco hacia abajo para evitar el use after free. [wsa: comentario agregado al código, etiqueta de correcciones agregada] An out-of-bounds (OOB) memory access flaw was found in the i2c driver module in the Linux kernel. • https://git.kernel.org/stable/c/611e12ea0f121a31d9e9c4ce2a18a77abc2f28d6 https://git.kernel.org/stable/c/e6412ba3b6508bdf9c074d310bf4144afa6aec1a https://git.kernel.org/stable/c/23a191b132cd87f746c62f3dc27da33683d85829 https://git.kernel.org/stable/c/871a1e94929a27bf6e2cd99523865c840bbc2d87 https://git.kernel.org/stable/c/81cb31756888bb062e92d2dca21cd629d77a46a9 https://git.kernel.org/stable/c/35927d7509ab9bf41896b7e44f639504eae08af7 https://git.kernel.org/stable/c/e8e1a046cf87c8b1363e5de835114f2779e2aaf4 https://git.kernel.org/stable/c/12b0606000d0828630c033bf0c74c7484 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26606 – binder: signal epoll threads of self-work
https://notcve.org/view.php?id=CVE-2024-26606
In the Linux kernel, the following vulnerability has been resolved: binder: signal epoll threads of self-work In (e)poll mode, threads often depend on I/O events to determine when data is ready for consumption. Within binder, a thread may initiate a command via BINDER_WRITE_READ without a read buffer and then make use of epoll_wait() or similar to consume any responses afterwards. It is then crucial that epoll threads are signaled via wakeup when they queue their own work. Otherwise, they risk waiting indefinitely for an event leaving their work unhandled. What is worse, subsequent commands won't trigger a wakeup either as the thread has pending work. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: carpeta: señal de epoll de subprocesos de autotrabajo En el modo (e)poll, los subprocesos a menudo dependen de eventos de E/S para determinar cuándo los datos están listos para el consumo. • https://git.kernel.org/stable/c/457b9a6f09f011ebcb9b52cc203a6331a6fc2de7 https://git.kernel.org/stable/c/dd64bb8329ce0ea27bc557e4160c2688835402ac https://git.kernel.org/stable/c/42beab162dcee1e691ee4934292d51581c29df61 https://git.kernel.org/stable/c/a423042052ec2bdbf1e552e621e6a768922363cc https://git.kernel.org/stable/c/82722b453dc2f967b172603e389ee7dc1b3137cc https://git.kernel.org/stable/c/90e09c016d72b91e76de25f71c7b93d94cc3c769 https://git.kernel.org/stable/c/a7ae586f6f6024f490b8546c8c84670f96bb9b68 https://git.kernel.org/stable/c/93b372c39c40cbf179e56621e6bc48240 •