CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52855 – usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency
https://notcve.org/view.php?id=CVE-2023-52855
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue(): spin_lock_irqsave(&hsotg->lock, flags); ... if (!urb->hcpriv) { dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n"); goto out; } rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv ... out: spin_unlock_irqrestore(&hsotg->lock, flags); When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are concurrently executed, the NULL check of "urb->hcpriv" can be executed before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL pointer dereference. This possible bug is found by an experimental static analysis tool developed by myself. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. • https://git.kernel.org/stable/c/33ad261aa62be02f0cedeb4d5735cc726de84a3f https://git.kernel.org/stable/c/14c9ec34e8118fbffd7f5431814d767726323e72 https://git.kernel.org/stable/c/fed492aa6493a91a77ebd51da6fb939c98d94a0d https://git.kernel.org/stable/c/64c47749fc7507ed732e155c958253968c1d275e https://git.kernel.org/stable/c/bdb3dd4096302d6b87441fdc528439f171b04be6 https://git.kernel.org/stable/c/fcaafb574fc88a52dce817f039f7ff2f9da38001 https://git.kernel.org/stable/c/6b21a22728852d020a6658d39cd7bb7e14b07790 https://git.kernel.org/stable/c/3e851a77a13ce944d703721793f49ee82 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 13EXPL: 0CVE-2023-52854 – padata: Fix refcnt handling in padata_free_shell()
https://notcve.org/view.php?id=CVE-2023-52854
In the Linux kernel, the following vulnerability has been resolved: padata: Fix refcnt handling in padata_free_shell() In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead to system UAF (Use-After-Free) issues. Due to the lengthy analysis of the pcrypt_aead01 function call, I'll describe the problem scenario using a simplified model: Suppose there's a user of padata named `user_function` that adheres to the padata requirement of calling `padata_free_shell` after `serial()` has been invoked, as demonstrated in the following code: ```c struct request { struct padata_priv padata; struct completion *done; }; void parallel(struct padata_priv *padata) { do_something(); } void serial(struct padata_priv *padata) { struct request *request = container_of(padata, struct request, padata); complete(request->done); } void user_function() { DECLARE_COMPLETION(done) padata->parallel = parallel; padata->serial = serial; padata_do_parallel(); wait_for_completion(&done); padata_free_shell(); } ``` In the corresponding padata.c file, there's the following code: ```c static void padata_serial_worker(struct work_struct *serial_work) { ... cnt = 0; while (!list_empty(&local_list)) { ... padata->serial(padata); cnt++; } local_bh_enable(); if (refcount_sub_and_test(cnt, &pd->refcnt)) padata_free_pd(pd); } ``` Because of the high system load and the accumulation of unexecuted softirq at this moment, `local_bh_enable()` in padata takes longer to execute than usual. Subsequently, when accessing `pd->refcnt`, `pd` has already been released by `padata_free_shell()`, resulting in a UAF issue with `pd->refcnt`. The fix is straightforward: add `refcount_dec_and_test` before calling `padata_free_pd` in `padata_free_shell`. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: padata: corrige el manejo de refcnt en padata_free_shell(). • https://git.kernel.org/stable/c/07928d9bfc81640bab36f5190e8725894d93b659 https://git.kernel.org/stable/c/13721e447acc2b82c19cf72e9e6c4291c77693ed https://git.kernel.org/stable/c/7a2ccb65f90168edc2348495bb56093c466ffa39 https://git.kernel.org/stable/c/928cf3d733c4efc221e1a78b14cb2ee066627260 https://git.kernel.org/stable/c/c9da8ee1491719001a444f4af688b75e72b58418 https://git.kernel.org/stable/c/dc34710a7aba5207e7cb99d11588c04535b3c53d https://git.kernel.org/stable/c/5fefc9b3e3584a1ce98da27c38e1b8dda1939d74 https://git.kernel.org/stable/c/26daf8e6515c2dcd25d235468420b9f46 •
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: 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 •