CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52840 – Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()
https://notcve.org/view.php?id=CVE-2023-52840
In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - fix use after free in rmi_unregister_function() The put_device() calls rmi_release_function() which frees "fn" so the dereference on the next line "fn->num_of_irqs" is a use after free. Move the put_device() to the end to fix this. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Entrada: synaptics-rmi4 - corrige el use after free en rmi_unregister_function(). El put_device() llama a rmi_release_function() que libera "fn", por lo que se elimina la referencia en la siguiente línea "fn-> num_of_irqs" es un uso después de ser gratuito. Mueva put_device() hasta el final para solucionar este problema. • https://git.kernel.org/stable/c/24d28e4f1271cb2f91613dada8f2acccd00eff56 https://git.kernel.org/stable/c/2f236d8638f5b43e0c72919a6a27fe286c32053f https://git.kernel.org/stable/c/50d12253666195a14c6cd2b81c376e2dbeedbdff https://git.kernel.org/stable/c/6c71e065befb2fae8f1461559b940c04e1071bd5 https://git.kernel.org/stable/c/303766bb92c5c225cf40f9bbbe7e29749406e2f2 https://git.kernel.org/stable/c/7082b1fb5321037bc11ba1cf2d7ed23c6b2b521f https://git.kernel.org/stable/c/cc56c4d17721dcb10ad4e9c9266e449be1462683 https://git.kernel.org/stable/c/c8e639f5743cf4b01f8c65e0df075fe4d • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2023-52838 – fbdev: imsttfb: fix a resource leak in probe
https://notcve.org/view.php?id=CVE-2023-52838
In the Linux kernel, the following vulnerability has been resolved: fbdev: imsttfb: fix a resource leak in probe I've re-written the error handling but the bug is that if init_imstt() fails we need to call iounmap(par->cmap_regs). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fbdev: imsttfb: corrige una fuga de recursos en la sonda. He reescrito el manejo de errores, pero el error es que si init_imstt() falla, debemos llamar a iounmap(par-> cmap_regs). • https://git.kernel.org/stable/c/7f683f286a2196bd4d2da420a3194f5ba0269d8c https://git.kernel.org/stable/c/815c95d82b79bb32e9aa7c95c6ac7cb1c92612cd https://git.kernel.org/stable/c/2bf70b88cc358a437db376826f92c8dcf9c23587 https://git.kernel.org/stable/c/ad3de274e065790181f112b9c72a2fb4665ee2fd https://git.kernel.org/stable/c/c6c0a9f619584be19726ce7f81c31bc555af401a https://git.kernel.org/stable/c/c75f5a55061091030a13fef71b9995b89bc86213 https://git.kernel.org/stable/c/64c6b84c73f576380fadeec2d30aaeccbc2994c7 https://git.kernel.org/stable/c/4c86974fb42281b8041a504d92ab341ad •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52836 – locking/ww_mutex/test: Fix potential workqueue corruption
https://notcve.org/view.php?id=CVE-2023-52836
In the Linux kernel, the following vulnerability has been resolved: locking/ww_mutex/test: Fix potential workqueue corruption In some cases running with the test-ww_mutex code, I was seeing odd behavior where sometimes it seemed flush_workqueue was returning before all the work threads were finished. Often this would cause strange crashes as the mutexes would be freed while they were being used. Looking at the code, there is a lifetime problem as the controlling thread that spawns the work allocates the "struct stress" structures that are passed to the workqueue threads. Then when the workqueue threads are finished, they free the stress struct that was passed to them. Unfortunately the workqueue work_struct node is in the stress struct. Which means the work_struct is freed before the work thread returns and while flush_workqueue is waiting. It seems like a better idea to have the controlling thread both allocate and free the stress structures, so that we can be sure we don't corrupt the workqueue by freeing the structure prematurely. So this patch reworks the test to do so, and with this change I no longer see the early flush_workqueue returns. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: lock/ww_mutex/test: soluciona una posible corrupción de la cola de trabajo. En algunos casos, al ejecutar el código test-ww_mutex, veía un comportamiento extraño en el que a veces parecía que flush_workqueue regresaba antes que todos los subprocesos de trabajo. hemos terminado. • https://git.kernel.org/stable/c/d4d37c9e6a4dbcca958dabd99216550525c7e389 https://git.kernel.org/stable/c/d8267cabbe1bed15ccf8b0e684c528bf8eeef715 https://git.kernel.org/stable/c/dcd85e3c929368076a7592b27f541e0da8b427f5 https://git.kernel.org/stable/c/9ed2d68b3925145f5f51c46559484881d6082f75 https://git.kernel.org/stable/c/e89d0ed45a419c485bae999426ecf92697cbdda3 https://git.kernel.org/stable/c/c56df79d68677cf062da1b6e3b33e74299a92dfc https://git.kernel.org/stable/c/e36407713163363e65566e7af0abe207d5f59a0c https://git.kernel.org/stable/c/304a2c4aad0fff887ce493e4197bf9cba •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52835 – perf/core: Bail out early if the request AUX area is out of bound
https://notcve.org/view.php?id=CVE-2023-52835
In the Linux kernel, the following vulnerability has been resolved: perf/core: Bail out early if the request AUX area is out of bound When perf-record with a large AUX area, e.g 4GB, it fails with: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory) and it reveals a WARNING with __alloc_pages(): ------------[ cut here ]------------ WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248 Call trace: __alloc_pages+0x1ec/0x248 __kmalloc_large_node+0xc0/0x1f8 __kmalloc_node+0x134/0x1e8 rb_alloc_aux+0xe0/0x298 perf_mmap+0x440/0x660 mmap_region+0x308/0x8a8 do_mmap+0x3c0/0x528 vm_mmap_pgoff+0xf4/0x1b8 ksys_mmap_pgoff+0x18c/0x218 __arm64_sys_mmap+0x38/0x58 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x58/0x188 do_el0_svc+0x34/0x50 el0_svc+0x34/0x108 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a4/0x1a8 'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to maintains AUX trace pages. The allocated page for this array is physically contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the size of pointer array crosses the limitation set by MAX_ORDER, it reveals a WARNING. So bail out early with -ENOMEM if the request AUX area is out of bound, e.g.: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/core: rescate anticipado si el área AUX de la solicitud está fuera de los límites. Cuando perf-record con un área AUX grande, por ejemplo, 4 GB, falla con: #perf record -C 0 -m, 4G -e arm_spe_0// -- el sueño 1 no pudo mapear con 12 (no se puede asignar memoria) y revela una ADVERTENCIA con __alloc_pages(): ------------[ cortar aquí ] ------------ ADVERTENCIA: CPU: 44 PID: 17573 en mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248 Rastreo de llamadas: __alloc_pages+0x1ec/0x248 __kmalloc_large_node+0xc0/0x1f8 __kmalloc_node+0x134/ 0x1e8 rb_alloc_aux+0xe0/0x298 perf_mmap+0x440/0x660 mmap_region+0x308/0x8a8 do_mmap+0x3c0/0x528 vm_mmap_pgoff+0xf4/0x1b8 ksys_mmap_pgoff+0x18c/0x218 sys_mmap+0x38/0x58 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x58/0x188 do_el0_svc+0x34/0x50 el0_svc+0x34/0x108 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a4/0x1a8 'rb->aux_pages' asignado por kcalloc() es una matriz de punteros que se utiliza para mantener páginas de seguimiento AUX. • https://git.kernel.org/stable/c/8c504f615d7ed60ae035c51d0c789137ced6797f https://git.kernel.org/stable/c/788c0b3442ead737008934947730a6d1ff703734 https://git.kernel.org/stable/c/1a2a4202c60fcdffbf04f259002ce9bff39edece https://git.kernel.org/stable/c/fd0df3f8719201dbe61a4d39083d5aecd705399a https://git.kernel.org/stable/c/9ce4e87a8efd37c85766ec08b15e885cab08553a https://git.kernel.org/stable/c/2424410f94a94d91230ced094062d859714c984a https://git.kernel.org/stable/c/2e905e608e38cf7f8dcddcf8a6036e91a78444cb https://git.kernel.org/stable/c/54aee5f15b83437f23b2b2469bcf21bdd • CWE-125: Out-of-bounds Read •
CVSS: 4.4EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52834 – atl1c: Work around the DMA RX overflow issue
https://notcve.org/view.php?id=CVE-2023-52834
In the Linux kernel, the following vulnerability has been resolved: atl1c: Work around the DMA RX overflow issue This is based on alx driver commit 881d0327db37 ("net: alx: Work around the DMA RX overflow issue"). The alx and atl1c drivers had RX overflow error which was why a custom allocator was created to avoid certain addresses. The simpler workaround then created for alx driver, but not for atl1c due to lack of tester. Instead of using a custom allocator, check the allocated skb address and use skb_reserve() to move away from problematic 0x...fc0 address. Tested on AR8131 on Acer 4540. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atl1c:workaround al problema de desbordamiento de DMA RX. Esto se basa en la confirmación del controlador alx 881d0327db37 ("net: alx: solución alternativa al problema de desbordamiento de DMA RX"). Los controladores alx y atl1c tenían un error de desbordamiento de RX, por lo que se creó un asignador personalizado para evitar ciertas direcciones. • https://git.kernel.org/stable/c/c29a89b23f67ee592f4dee61f9d7efbf86d60315 https://git.kernel.org/stable/c/57e44ff9c2c9747b2b1a53556810b0e5192655d6 https://git.kernel.org/stable/c/54a6152da4993ec8e4b53dc3cf577f5a2c829afa https://git.kernel.org/stable/c/32f08b7b430ee01ec47d730f961a3306c1c7b6fb https://git.kernel.org/stable/c/86565682e9053e5deb128193ea9e88531bbae9cf https://access.redhat.com/security/cve/CVE-2023-52834 https://bugzilla.redhat.com/show_bug.cgi?id=2282744 • CWE-125: Out-of-bounds Read •