CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52853 – hid: cp2112: Fix duplicate workqueue initialization
https://notcve.org/view.php?id=CVE-2023-52853
In the Linux kernel, the following vulnerability has been resolved: hid: cp2112: Fix duplicate workqueue initialization Previously the cp2112 driver called INIT_DELAYED_WORK within cp2112_gpio_irq_startup, resulting in duplicate initilizations of the workqueue on subsequent IRQ startups following an initial request. This resulted in a warning in set_work_data in workqueue.c, as well as a rare NULL dereference within process_one_work in workqueue.c. Initialize the workqueue within _probe instead. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hid: cp2112: corrige la inicialización duplicada de la cola de trabajo. Anteriormente, el controlador cp2112 llamaba INIT_DELAYED_WORK dentro de cp2112_gpio_irq_startup, lo que generaba inicializaciones duplicadas de la cola de trabajo en inicios IRQ posteriores después de una solicitud inicial. Esto resultó en una advertencia en set_work_data en workqueue.c, así como en una rara desreferencia NULL dentro de process_one_work en workqueue.c. • https://git.kernel.org/stable/c/13de9cca514ed63604263cad87ca8cb36e9b6489 https://git.kernel.org/stable/c/df0daac2709473531d6a3472997cc65301ac06d6 https://git.kernel.org/stable/c/727203e6e7e7020e1246fc1628cbdb8d90177819 https://git.kernel.org/stable/c/3d959406c8fff2334d83d0c352d54fd6f5b2e7cd https://git.kernel.org/stable/c/012d0c66f9392a99232ac28217229f32dd3a70cf https://git.kernel.org/stable/c/bafb12b629b7c3ad59812dd1ac1b0618062e0e38 https://git.kernel.org/stable/c/fb5718bc67337dde1528661f419ffcf275757592 https://git.kernel.org/stable/c/eb1121fac7986b30915ba20c5a04cc01f •
CVSS: 4.4EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52845 – tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
https://notcve.org/view.php?id=CVE-2023-52845
In the Linux kernel, the following vulnerability has been resolved: tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING syzbot reported the following uninit-value access issue [1]: ===================================================== BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline] BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756 strlen lib/string.c:418 [inline] strstr+0xb8/0x2f0 lib/string.c:756 tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595 genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline] genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066 netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline] netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd TIPC bearer-related names including link names must be null-terminated strings. If a link name which is not null-terminated is passed through netlink, strstr() and similar functions can cause buffer overrun. This causes the above issue. This patch changes the nla_policy for bearer-related names from NLA_STRING to NLA_NUL_STRING. This resolves the issue by ensuring that only null-terminated strings are accepted as bearer-related names. syzbot reported similar uninit-value issue related to bearer names [2]. The root cause of this issue is that a non-null-terminated bearer name was passed. • https://git.kernel.org/stable/c/7be57fc6918470ecacd16b89c0d4f73d8fc265c4 https://git.kernel.org/stable/c/6744008c354bca2e4686a5b6056ee6b535d9f67d https://git.kernel.org/stable/c/2426425d686b43adbc4f2f4a367b494f06f159d6 https://git.kernel.org/stable/c/2199260c42e6fbc5af8adae3bf78e623407c91b0 https://git.kernel.org/stable/c/b33d130f07f1decd756b849ab03c23d11d4dd294 https://git.kernel.org/stable/c/3907b89cd17fcc23e9a80789c36856f00ece0ba8 https://git.kernel.org/stable/c/4c731e98fe4d678e87ba3e4d45d3cf0a5a193dc4 https://git.kernel.org/stable/c/abc1582119e8c4af14cedb0db6541fd60 • CWE-476: NULL Pointer Dereference •
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: 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 •