CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52841 – media: vidtv: mux: Add check and kfree for kstrdup
https://notcve.org/view.php?id=CVE-2023-52841
In the Linux kernel, the following vulnerability has been resolved: media: vidtv: mux: Add check and kfree for kstrdup Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Moreover, use kfree() in the later error handling in order to avoid memory leak. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: vidtv: mux: Add check and kfree for kstrdup. Agregue check para el valor de retorno de kstrdup() y devuelva el error si falla para evitar la desreferencia al puntero NULL. Además, utilice kfree() en el manejo de errores posterior para evitar pérdidas de memoria. • https://git.kernel.org/stable/c/c2f78f0cb294aa6f009d3a170f4ee8ad199ba5da https://git.kernel.org/stable/c/64863ba8e6b7651d994c6e6d506cc8aa2ac45edb https://git.kernel.org/stable/c/980be4c3b0d51c0f873fd750117774561c66cf68 https://git.kernel.org/stable/c/a254ee1ddc592ae1efcce96b8c014e1bd2d5a2b4 https://git.kernel.org/stable/c/cb13001411999adb158b39e76d94705eb2da100d https://git.kernel.org/stable/c/aae7598aff291d4d140be1355aa20930af948785 https://git.kernel.org/stable/c/1fd6eb12642e0c32692924ff359c07de4b781d78 •
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: 2EXPL: 0CVE-2023-52839 – drivers: perf: Do not broadcast to other cpus when starting a counter
https://notcve.org/view.php?id=CVE-2023-52839
In the Linux kernel, the following vulnerability has been resolved: drivers: perf: Do not broadcast to other cpus when starting a counter This command: $ perf record -e cycles:k -e instructions:k -c 10000 -m 64M dd if=/dev/zero of=/dev/null count=1000 gives rise to this kernel warning: [ 444.364395] WARNING: CPU: 0 PID: 104 at kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436 [ 444.364515] Modules linked in: [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec Not tainted 6.6.0-rc6-00051-g391df82e8ec3-dirty #73 [ 444.364771] Hardware name: riscv-virtio,qemu (DT) [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436 [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32 [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800 [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0 [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0 [ 444.364998] s1 : ff60000002c54d98 a0 : ff60000002a73940 a1 : 0000000000000000 [ 444.365013] a2 : 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100 [ 444.365029] a5 : 0000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000 [ 444.365044] s2 : 0000000000000000 s3 : ffffffffffffffff s4 : ff60000002c54d98 [ 444.365060] s5 : ffffffff81539610 s6 : ffffffff80c20c48 s7 : 0000000000000000 [ 444.365075] s8 : 0000000000000000 s9 : 0000000000000001 s10: 0000000000000001 [ 444.365090] s11: ffffffff80099394 t3 : 0000000000000003 t4 : 00000000eac0c6e6 [ 444.365104] t5 : 0000000400000000 t6 : ff60000002e010d0 [ 444.365120] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 444.365226] [<ffffffff8009f9e0>] smp_call_function_many_cond+0x42c/0x436 [ 444.365295] [<ffffffff8009fa5a>] on_each_cpu_cond_mask+0x20/0x32 [ 444.365311] [<ffffffff806e90dc>] pmu_sbi_ctr_start+0x7a/0xaa [ 444.365327] [<ffffffff806e880c>] riscv_pmu_start+0x48/0x66 [ 444.365339] [<ffffffff8012111a>] perf_adjust_freq_unthr_context+0x196/0x1ac [ 444.365356] [<ffffffff801237aa>] perf_event_task_tick+0x78/0x8c [ 444.365368] [<ffffffff8003faf4>] scheduler_tick+0xe6/0x25e [ 444.365383] [<ffffffff8008a042>] update_process_times+0x80/0x96 [ 444.365398] [<ffffffff800991ec>] tick_sched_handle+0x26/0x52 [ 444.365410] [<ffffffff800993e4>] tick_sched_timer+0x50/0x98 [ 444.365422] [<ffffffff8008a6aa>] __hrtimer_run_queues+0x126/0x18a [ 444.365433] [<ffffffff8008b350>] hrtimer_interrupt+0xce/0x1da [ 444.365444] [<ffffffff806cdc60>] riscv_timer_interrupt+0x30/0x3a [ 444.365457] [<ffffffff8006afa6>] handle_percpu_devid_irq+0x80/0x114 [ 444.365470] [<ffffffff80065b82>] generic_handle_domain_irq+0x1c/0x2a [ 444.365483] [<ffffffff8045faec>] riscv_intc_irq+0x2e/0x46 [ 444.365497] [<ffffffff808a9c62>] handle_riscv_irq+0x4a/0x74 [ 444.365521] [<ffffffff808aa760>] do_irq+0x7c/0x7e [ 444.365796] ---[ end trace 0000000000000000 ]--- That's because the fix in commit 3fec323339a4 ("drivers: perf: Fix panic in riscv SBI mmap support") was wrong since there is no need to broadcast to other cpus when starting a counter, that's only needed in mmap when the counters could have already been started on other cpus, so simply remove this broadcast. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: controladores: perf: no transmitir a otras CPU al iniciar un contador. Este comando: $ perf record -e ciclos:k -e instrucciones:k -c 10000 -m 64M dd if =/dev/zero of=/dev/null count=1000 da lugar a esta advertencia del kernel: [444.364395] ADVERTENCIA: CPU: 0 PID: 104 en kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436 [444.364515] Módulos vinculados en: [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec No contaminado 6.6.0-rc6-00051-g391df82e8ec3-dirty #73 [ 444.364771] Nombre de hardware: riscv-virtio,qemu (DT) [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436 [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32 [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800 [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0 [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0 [444.364998] s1: ff60000002c54d98 a0: ff60000002a73940 a1: 0000000000000000 [444.365013] a2: 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100 [ 444.365029 ] a5 : 000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000 [ 444.365044] s2: 0000000000000000 s3: ffffffffffffffff s4: ff60000002c54d98 [ 444.365060] s5: ffffffff81539610 s6: ffffffff80c20c48 s7: 0000000000000000 [444.365075] s8: 0000000000000000 s9: 0000000000000001 s10: 0000000000000001 [444.365090] s11: ffffffff80099394 t3: 0000000000000003 t4: 00000000eac0c6e6 [444.365104] t5: 0000000400000000 t6: ff60000002e010d0 [444.365120] estado: 0000000200000100 badaddr: 0000000000000000 causa: 0000000000000003 [444.365226] [] smp_call_function_many_cond+0x42c/0x436 [444.365295] [] on_each_cpu_cond_mask+0x20/0x32 [ 444.365311] [] pmu_sbi_ctr_start+0x7a/0xaa [ 444.365327] [< ffffffff806e880c>] riscv_pmu_start+0x48/0x66 [ 444.365339] [] perf_adjust_freq_unthr_context+0x196/0x1ac [ 444.365356] [] _task_tick+0x78/0x8c [ 444.365368] [] scheduler_tick+0xe6/0x25e [ 444.365383] [] update_process_times+0x80/0x96 [ 444.365398] [] tick_sched_handle+0x26/0x52 [ 444.365410] [] [ 444.365422] [] __hrtimer_run_queues+0x126/0x18a [ 444.365433] [] hrtimer_interrupt+0xce/0x1da [ 444.365444] [] riscv_timer_interrupt+0x30/0x3a [ 444.365457] [] cpu_devid_irq+0x80/0x114 [ 444.365470] [] generic_handle_domain_irq+0x1c/ 0x2a [ 444.365483] [] riscv_intc_irq+0x2e/0x46 [ 444.365497] [] handle_riscv_irq+0x4a/0x74 [ 444.365521 [] do_irq+0x7c/0x7e [ 444.365796] ---[ final de seguimiento 0000000000000000 ]--- Esto se debe a que la solución en la confirmación 3fec323339a4 ("drivers: perf: Fix panic in riscv SBI mmap support") era incorrecta ya que no hay necesidad de transmitir a otras CPU al iniciar un contador, eso solo es necesario en mmap cuando el Es posible que los contadores ya se hayan iniciado en otras CPU, así que simplemente elimine esta transmisión. • https://git.kernel.org/stable/c/3fec323339a4a9801a54e8b282eb571965b67b23 https://git.kernel.org/stable/c/85be1a73fd298ed3fd060dfce97caef5f9928c57 https://git.kernel.org/stable/c/61e3d993c8bd3e80f8f1363ed5e04f88ab531b72 •
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: 4EXPL: 0CVE-2023-52837 – nbd: fix uaf in nbd_open
https://notcve.org/view.php?id=CVE-2023-52837
In the Linux kernel, the following vulnerability has been resolved: nbd: fix uaf in nbd_open Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won't set disk->private_data as NULL as before. UAF may be triggered in nbd_open() if someone tries to open nbd device right after nbd_put() since nbd has been free in nbd_dev_remove(). Fix this by implementing ->free_disk and free private data in it. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nbd: corrija uaf en nbd_open Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk y blk_cleanup_disk") limpia el disco mediante blk_cleanup_disk() y no configurará disk->private_data como NULL como antes. UAF puede activarse en nbd_open() si alguien intenta abrir el dispositivo nbd justo después de nbd_put() ya que nbd ha estado libre en nbd_dev_remove(). Solucione este problema implementando ->free_disk y datos privados gratuitos en él. • https://git.kernel.org/stable/c/4af5f2e0301311f88c420fcfc5f3c8611ade20ac https://git.kernel.org/stable/c/4e9b3ec84dc97909876641dad14e0a2300d6c2a3 https://git.kernel.org/stable/c/879947f4180bc6e83af64eb0515e0cf57fce15db https://git.kernel.org/stable/c/56bd7901b5e9dbc9112036ea615ebcba1565fafe https://git.kernel.org/stable/c/327462725b0f759f093788dfbcb2f1fd132f956b •