CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47433 – btrfs: fix abort logic in btrfs_replace_file_extents
https://notcve.org/view.php?id=CVE-2021-47433
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix abort logic in btrfs_replace_file_extents Error injection testing uncovered a case where we'd end up with a corrupt file system with a missing extent in the middle of a file. This occurs because the if statement to decide if we should abort is wrong. The only way we would abort in this case is if we got a ret != -EOPNOTSUPP and we called from the file clone code. However the prealloc code uses this path too. Instead we need to abort if there is an error, and the only error we _don't_ abort on is -EOPNOTSUPP and only if we came from the clone file code. • https://git.kernel.org/stable/c/0e32a2b85c7d92ece86c17dfef390c5ed79c6378 https://git.kernel.org/stable/c/0e309e1152fc34ef75991d9d69b165dbf75bf26c https://git.kernel.org/stable/c/4afb912f439c4bc4e6a4f3e7547f2e69e354108f •
CVSS: 4.4EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52878 – can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds
https://notcve.org/view.php?id=CVE-2023-52878
In the Linux kernel, the following vulnerability has been resolved: can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds If the "struct can_priv::echoo_skb" is accessed out of bounds, this would cause a kernel crash. Instead, issue a meaningful warning message and return with an error. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: dev: can_put_echo_skb(): no bloquee el kernel si se accede a can_priv::echo_skb fuera de los límites. Si se accede a "struct can_priv::echoo_skb" fuera de los límites, esto provocaría un fallo del kernel. En su lugar, emita un mensaje de advertencia significativo y regrese con un error. • https://git.kernel.org/stable/c/a6e4bc5304033e434fabccabb230b8e9ff55d76f https://git.kernel.org/stable/c/826120c9ba68f2d0dbae58e99013929c883d1444 https://git.kernel.org/stable/c/0d30931f1fa0fb893fb7d5dc32b6b7edfb775be4 https://git.kernel.org/stable/c/53c468008a7c9ca3f5fc985951f35ec2acae85bc https://git.kernel.org/stable/c/8ab67da060157362b2e0926692c659808784708f https://git.kernel.org/stable/c/6411959c10fe917288cbb1038886999148560057 https://access.redhat.com/security/cve/CVE-2023-52878 https://bugzilla.redhat.com/show_bug.cgi?id=2282680 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52868 – thermal: core: prevent potential string overflow
https://notcve.org/view.php?id=CVE-2023-52868
In the Linux kernel, the following vulnerability has been resolved: thermal: core: prevent potential string overflow The dev->id value comes from ida_alloc() so it's a number between zero and INT_MAX. If it's too high then these sprintf()s will overflow. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: térmica: núcleo: evita un posible desbordamiento de cadenas. El valor dev->id proviene de ida_alloc(), por lo que es un número entre cero e INT_MAX. Si es demasiado alto, estos sprintf()s se desbordarán. • https://git.kernel.org/stable/c/203d3d4aa482339b4816f131f713e1b8ee37f6dd https://git.kernel.org/stable/c/b55f0a9f865be75ca1019aad331f3225f7b50ce8 https://git.kernel.org/stable/c/6ad1bf47fbe5750c4d5d8e41337665e193e2c521 https://git.kernel.org/stable/c/3091ab943dfc7b2578599b0fe203350286fab5bb https://git.kernel.org/stable/c/3f795fb35c2d8a637efe76b4518216c9319b998c https://git.kernel.org/stable/c/3a8f4e58e1ee707b4f46a1000b40b86ea3dd509c https://git.kernel.org/stable/c/77ff34a56b695e228e6daf30ee30be747973d6e8 https://git.kernel.org/stable/c/0f6b3be28c4d62ef6498133959c722666 •
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 •