CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52846 – hsr: Prevent use after free in prp_create_tagged_frame()
https://notcve.org/view.php?id=CVE-2023-52846
In the Linux kernel, the following vulnerability has been resolved: hsr: Prevent use after free in prp_create_tagged_frame() The prp_fill_rct() function can fail. In that situation, it frees the skb and returns NULL. Meanwhile on the success path, it returns the original skb. So it's straight forward to fix bug by using the returned value. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hsr: impedir el uso después de liberar en prp_create_tagged_frame(). • https://git.kernel.org/stable/c/451d8123f89791bb628277c0bdb4cae34a3563e6 https://git.kernel.org/stable/c/ddf4e04e946aaa6c458b8b6829617cc44af2bffd https://git.kernel.org/stable/c/a1a485e45d24b1cd8fe834fd6f1b06e2903827da https://git.kernel.org/stable/c/6086258bd5ea7b5c706ff62da42b8e271b2401db https://git.kernel.org/stable/c/1787b9f0729d318d67cf7c5a95f0c3dba9a7cc18 https://git.kernel.org/stable/c/d103fb6726904e353b4773188ee3d3acb4078363 https://git.kernel.org/stable/c/876f8ab52363f649bcc74072157dfd7adfbabc0d •
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: 6.2EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52844 – media: vidtv: psi: Add check for kstrdup
https://notcve.org/view.php?id=CVE-2023-52844
In the Linux kernel, the following vulnerability has been resolved: media: vidtv: psi: Add check for kstrdup Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: vidtv: psi: Agregar verificación para kstrdup. Agregue verificación para el valor de retorno de kstrdup() y devuelva el error si falla para evitar la desreferencia al puntero NULL. • https://git.kernel.org/stable/c/7a7899f6f58e3270ccfd200ee63ebced5ddba3c9 https://git.kernel.org/stable/c/3387490c89b10aeb4e71d78b65dbc9ba4b2385b9 https://git.kernel.org/stable/c/d17269fb9161995303985ab2fe6f16cfb72152f9 https://git.kernel.org/stable/c/5c26aae3723965c291c65dd2ecad6a3240d422b0 https://git.kernel.org/stable/c/5cfcc8de7d733a1137b86954cc28ce99972311ad https://git.kernel.org/stable/c/a51335704a3f90eaf23a6864faefca34b382490a https://git.kernel.org/stable/c/76a2c5df6ca8bd8ada45e953b8c72b746f42918d • 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: 2EXPL: 0CVE-2023-52842 – virtio/vsock: Fix uninit-value in virtio_transport_recv_pkt()
https://notcve.org/view.php?id=CVE-2023-52842
In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix uninit-value in virtio_transport_recv_pkt() KMSAN reported the following uninit-value access issue: ===================================================== BUG: KMSAN: uninit-value in virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421 virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421 vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120 process_one_work kernel/workqueue.c:2630 [inline] process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703 worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784 kthread+0x3cc/0x520 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 Uninit was stored to memory at: virtio_transport_space_update net/vmw_vsock/virtio_transport_common.c:1274 [inline] virtio_transport_recv_pkt+0x1ee8/0x26a0 net/vmw_vsock/virtio_transport_common.c:1415 vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120 process_one_work kernel/workqueue.c:2630 [inline] process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703 worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784 kthread+0x3cc/0x520 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 Uninit was created at: slab_post_alloc_hook+0x105/0xad0 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5a2/0xaf0 mm/slub.c:3523 kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x2fd/0x770 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] virtio_vsock_alloc_skb include/linux/virtio_vsock.h:66 [inline] virtio_transport_alloc_skb+0x90/0x11e0 net/vmw_vsock/virtio_transport_common.c:58 virtio_transport_reset_no_sock net/vmw_vsock/virtio_transport_common.c:957 [inline] virtio_transport_recv_pkt+0x1279/0x26a0 net/vmw_vsock/virtio_transport_common.c:1387 vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120 process_one_work kernel/workqueue.c:2630 [inline] process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703 worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784 kthread+0x3cc/0x520 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 CPU: 1 PID: 10664 Comm: kworker/1:5 Not tainted 6.6.0-rc3-00146-g9f3ebbef746f #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014 Workqueue: vsock-loopback vsock_loopback_work ===================================================== The following simple reproducer can cause the issue described above: int main(void) { int sock; struct sockaddr_vm addr = { .svm_family = AF_VSOCK, .svm_cid = VMADDR_CID_ANY, .svm_port = 1234, }; sock = socket(AF_VSOCK, SOCK_STREAM, 0); connect(sock, (struct sockaddr *)&addr, sizeof(addr)); return 0; } This issue occurs because the `buf_alloc` and `fwd_cnt` fields of the `struct virtio_vsock_hdr` are not initialized when a new skb is allocated in `virtio_transport_init_hdr()`. This patch resolves the issue by initializing these fields during allocation. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio/vsock: corrige el valor uninit en virtio_transport_recv_pkt(). KMSAN informó el siguiente problema de acceso al valor uninit: ================ ===================================== ERROR: KMSAN: valor uninit en virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421 virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421 vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120 Process_one_work workqueue.c:2630 [en línea] process_scheduled_works+ 0xff6/0x1e60 kernel/workqueue.c:2703 worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784 kthread+0x3cc/0x520 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 Uninit se almacenó en la memoria en: virtio_transport_space_update net/vmw_vsock/virtio_transport_common.c:1274 [en línea] virtio_transport_recv_pkt+0x1ee8/0x26a0 net/vmw_vsock/virt io_transport_common.c:1415 vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120 Process_one_work kernel/workqueue.c:2630 [en línea] Process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703 trabajador_thread+0xeca/0x14d0 kernel/workqueue.c:2784 hilo +0x3cc/0x520 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 Uninit se creó en: slab_post_alloc_hook+ 0x105/0xad0 mm/slab.h: 767 slab_alloc_node mm/slub.c: 3478 [inline] kmem_cache_alloc_node+0x5a2/0xaf0 mm/slub.c: 3523 kmalloc_reserve+0x13c/0x4a0 net/skbuff. fd /0x770 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [en línea] virtio_vsock_alloc_skb include/linux/virtio_vsock.h:66 [en línea] virtio_transport_alloc_skb+0x90/0x11e0 net/vmw_vsock/virtio_transport_common.c: 58 virtio_transport_reset_no_sock net/vmw_vsock/virtio_transport_common.c:957 [en línea] virtio_transport_recv_pkt+0x1279/0x26a0 net/vmw_vsock/virtio_transport_common.c:1387 vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/v sock_loopback.c:120 proceso_one_work kernel/workqueue.c:2630 [en línea] Process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703 trabajador_thread+0xeca/0x14d0 kernel/workqueue.c:2784 kthread+0x3cc/0x520 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/ Process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 CPU: 1 PID: 10664 Comm: kworker/1:5 No contaminado 6.6.0-rc3-00146-g9f3ebbef746f #3 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 01/04/2014 Cola de trabajo: vsock-loopback vsock_loopback_work ===================== ================================= El siguiente reproductor simple puede causar el problema descrito anteriormente: int main(void) { calcetín interno; struct sockaddr_vm addr = { .svm_family = AF_VSOCK, .svm_cid = VMADDR_CID_ANY, .svm_port = 1234, }; sock = socket(AF_VSOCK, SOCK_STREAM, 0); connect(socket, (struct sockaddr *)&addr, sizeof(addr)); return 0; } Este problema ocurre porque los campos `buf_alloc` y `fwd_cnt` de `struct virtio_vsock_hdr` no se inicializan cuando se asigna un nuevo skb en `virtio_transport_init_hdr()`. Este parche resuelve el problema inicializando estos campos durante la asignación. • https://git.kernel.org/stable/c/71dc9ec9ac7d3eee785cdc986c3daeb821381e20 https://git.kernel.org/stable/c/0b8906fb48b99e993d6e8a12539f618f4854dd26 https://git.kernel.org/stable/c/34c4effacfc329aeca5635a69fd9e0f6c90b4101 https://git.kernel.org/stable/c/cd12535b97dd7d18cf655ec78ce1cf1f29a576be •