CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52476 – perf/x86/lbr: Filter vsyscall addresses
https://notcve.org/view.php?id=CVE-2023-52476
In the Linux kernel, the following vulnerability has been resolved: perf/x86/lbr: Filter vsyscall addresses We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top): __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode() decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq() perf_event_nmi_handler() Within __insn_get_emulate_prefix() at frame 0, a macro is called: peek_nbyte_next(insn_byte_t, insn, i) Within this macro, this dereference occurs: (insn)->next_byte Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made, for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an address in the vsyscall region will trigger an oops due to an unhandled page fault. To fix the bug, filtering for vsyscalls can be done when determining the branch type. This patch will return a "none" branch if a kernel address if found to lie in the vsyscall region. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf/x86/lbr: Filtrar direcciones vsyscall Descubrimos que puede ocurrir un pánico cuando se realiza una vsyscall mientras el muestreo LBR está activo. • https://git.kernel.org/stable/c/403d201d1fd144cb249836dafb222f6375871c6c https://git.kernel.org/stable/c/3863989497652488a50f00e96de4331e5efabc6c https://git.kernel.org/stable/c/f71edacbd4f99c0e12fe4a4007ab4d687d0688db https://git.kernel.org/stable/c/e53899771a02f798d436655efbd9d4b46c0f9265 https://access.redhat.com/security/cve/CVE-2023-52476 https://bugzilla.redhat.com/show_bug.cgi?id=2267041 • CWE-404: Improper Resource Shutdown or Release •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52475 – Input: powermate - fix use-after-free in powermate_config_complete
https://notcve.org/view.php?id=CVE-2023-52475
In the Linux kernel, the following vulnerability has been resolved: Input: powermate - fix use-after-free in powermate_config_complete syzbot has found a use-after-free bug [1] in the powermate driver. This happens when the device is disconnected, which leads to a memory free from the powermate_device struct. When an asynchronous control message completes after the kfree and its callback is invoked, the lock does not exist anymore and hence the bug. Use usb_kill_urb() on pm->config to cancel any in-progress requests upon device disconnection. [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Entrada: powermate - corrige el use-after-free en powermate_config_complete syzbot ha encontrado un error de use-after-free [1] en el controlador powermate. Esto sucede cuando el dispositivo está desconectado, lo que genera una memoria libre de la estructura powermate_device. • https://git.kernel.org/stable/c/8677575c4f39d65bf0d719b5d20e8042e550ccb9 https://git.kernel.org/stable/c/67cace72606baf1758fd60feb358f4c6be92e1cc https://git.kernel.org/stable/c/5aa514100aaf59868d745196258269a16737c7bd https://git.kernel.org/stable/c/cd2fbfd8b922b7fdd50732e47d797754ab59cb06 https://git.kernel.org/stable/c/6a4a396386404e62fb59bc3bde48871a64a82b4f https://git.kernel.org/stable/c/2efe67c581a2a6122b328d4bb6f21b3f36f40d46 https://git.kernel.org/stable/c/e528b1b9d60743e0b26224e3fe7aa74c24b8b2f8 https://git.kernel.org/stable/c/5c15c60e7be615f05a45cd905093a54b1 •
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: 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 •