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 •
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 •