CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52843 – llc: verify mac len before reading mac header
https://notcve.org/view.php?id=CVE-2023-52843
In the Linux kernel, the following vulnerability has been resolved: llc: verify mac len before reading mac header LLC reads the mac header with eth_hdr without verifying that the skb has an Ethernet header. Syzbot was able to enter llc_rcv on a tun device. Tun can insert packets without mac len and with user configurable skb->protocol (passing a tun_pi header when not configuring IFF_NO_PI). BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline] BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline] llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218 __netif_receive_skb_one_core net/core/dev.c:5523 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637 netif_receive_skb_internal net/core/dev.c:5723 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5782 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002 Add a mac_len test before all three eth_hdr(skb) calls under net/llc. There are further uses in include/net/llc_pdu.h. All these are protected by a test skb->protocol == ETH_P_802_2. Which does not protect against this tun scenario. But the mac_len test added in this patch in llc_fixup_skb will indirectly protect those too. That is called from llc_rcv before any other LLC code. It is tempting to just add a blanket mac_len check in llc_rcv, but not sure whether that could break valid LLC paths that do not assume an Ethernet header. 802.2 LLC may be used on top of non-802.3 protocols in principle. • https://git.kernel.org/stable/c/f83f1768f833cb45bc93429fdc552252a4f55ac3 https://git.kernel.org/stable/c/900a4418e3f66a32db6baaf23f92b99c20ae6535 https://git.kernel.org/stable/c/9a3f9054a5227d7567cba1fb821df48ccecad10c https://git.kernel.org/stable/c/cbdcdf42d15dac74c7287679fb2a9d955f8feb1f https://git.kernel.org/stable/c/3a2653828ffc6101aef80bf58d5b77484239f779 https://git.kernel.org/stable/c/352887b3edd007cf9b0abc30fe9d98622acd859b https://git.kernel.org/stable/c/f980e9a57dfb9530f1f4ee41a2420f2a256d7b29 https://git.kernel.org/stable/c/0a720d0259ad3521ec6c9e4199f9f6fc7 •
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: 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 •