CVSS: 5.5EPSS: 0%CPEs: 15EXPL: 0CVE-2024-26633 – ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()
https://notcve.org/view.php?id=CVE-2024-26633
In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim() syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken. Reading frag_off can only be done if we pulled enough bytes to skb->head. Currently we might access garbage. [1] BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline] ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [inline] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [inline] ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098 __pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655 pskb_may_pull_reason include/linux/skbuff.h:2673 [inline] pskb_may_pull include/linux/skbuff.h:2681 [inline] ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline] ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [inline] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [inline] ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendms ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ip6_tunnel: corrige el manejo de NEXTHDR_FRAGMENT en ip6_tnl_parse_tlv_enc_lim() syzbot señaló [1] que el manejo de NEXTHDR_FRAGMENT no funciona. La lectura de frag_off solo se puede realizar si extraemos suficientes bytes para skb->head. Actualmente podríamos acceder a basura. [1] ERROR: KMSAN: valor uninit en ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [en línea] ip6_tnl_start_xmit+0x ab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __netdev_start_xmit incluye /linux/netdevice.h:4940 [en línea] netdev_start_xmit include/linux/netdevice.h:4954 [en línea] xmit_one net/core/dev.c:3548 [en línea] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c: 3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [en línea] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h :542 [en línea] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [en línea] ip6_output+0x3 23/ 0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [en línea] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [en línea] ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0 x105/0x190 neto/ipv4 /af_inet.c:847 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c :2638 __sys_sendmsg net/socket.c:2667 [en línea] __do_sys_sendmsg net/socket.c:2676 [en línea] __se_sys_sendmsg net/socket.c:2674 [en línea] __x64_sys_sendmsg+0x307/0x490 net/socket.c:267 4 do_syscall_x64 arco/ x86/entry/common.c:52 [en línea] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit se creó en: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [en línea] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [en línea] __kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c :1027 kmalloc_reserve+0x249/ 0x4a0 net/core/skbuff.c:582 pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098 __pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655 pskb_may_pull_reason include/linux/skbuff.h:2673 [en línea ] pskb_may_pull include/linux/skbuff.h:2681 [en línea] ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [en línea] ip6_tnl_start_xmit+0xab 2/0x1a70 neto/ipv6/ ip6_tunnel.c:1432 __netdev_start_xmit include/linux/netdevice.h:4940 [en línea] netdev_start_xmit include/linux/netdevice.h:4954 [en línea] xmit_one net/core/dev.c:3548 [en línea] dev_hard_start_xmit+0x247/0xa10 net /core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [en línea] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [en línea] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [en línea] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [en línea] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output .c:1952 [en línea] ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:9 20 inet_sendmsg +0x105/0x190 net/ipv4/af_inet.c:847 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea]---truncado--- • https://git.kernel.org/stable/c/fbfa743a9d2a0ffa24251764f10afc13eb21e739 https://git.kernel.org/stable/c/a6f6bb6bc04a5f88a31f47a6123d3fbf5ee8d694 https://git.kernel.org/stable/c/72bbf335e7aad09c88c50dbdd238f4faabd12174 https://git.kernel.org/stable/c/decccc92ee0a978a1c268b5df16824cb6384ed3c https://git.kernel.org/stable/c/d3d9b59ab32160e3cc4edcf7e5fa7cecb53a7d25 https://git.kernel.org/stable/c/d397f7035d2c754781bbe93b07b94d8cd898620c https://git.kernel.org/stable/c/41e07a7e01d951cfd4c9a7dac90c921269d89513 https://git.kernel.org/stable/c/a7fe4e5d06338e1a82b1977eca3740095 • CWE-20: Improper Input Validation •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26632 – block: Fix iterating over an empty bio with bio_for_each_folio_all
https://notcve.org/view.php?id=CVE-2024-26632
In the Linux kernel, the following vulnerability has been resolved: block: Fix iterating over an empty bio with bio_for_each_folio_all If the bio contains no data, bio_first_folio() calls page_folio() on a NULL pointer and oopses. Move the test that we've reached the end of the bio from bio_next_folio() to bio_first_folio(). [axboe: add unlikely() to error case] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloque: corrige la iteración sobre una biografía vacía con bio_for_each_folio_all Si la biografía no contiene datos, bio_first_folio() llama a page_folio() en un puntero NULL y ¡vaya! Mueve la prueba de que hemos llegado al final de la biografía de bio_next_folio() a bio_first_folio(). [axboe: agregue improbable() al caso de error] • https://git.kernel.org/stable/c/640d1930bef4f87ec8d8d2b05f0f6edc1dfcf662 https://git.kernel.org/stable/c/c6350b5cb78e9024c49eaee6fdb914ad2903a5fe https://git.kernel.org/stable/c/a6bd8182137a12d22d3f2cee463271bdcb491659 https://git.kernel.org/stable/c/ca3ede3f5893e2d26d4dbdef1eec28a8487fafde https://git.kernel.org/stable/c/7bed6f3d08b7af27b7015da8dc3acf2b9c1f21d7 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26631 – ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work
https://notcve.org/view.php?id=CVE-2024-26631
In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work idev->mc_ifc_count can be written over without proper locking. Originally found by syzbot [1], fix this issue by encapsulating calls to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with mutex_lock() and mutex_unlock() accordingly as these functions should only be called with mc_lock per their declarations. [1] BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ... write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ... En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: mcast: corrige data-race en ipv6_mc_down / mld_ifc_work idev->mc_ifc_count se puede sobrescribir sin el bloqueo adecuado. Originalmente encontrado por syzbot [1], solucione este problema encapsulando las llamadas a mld_ifc_stop_work() (y mld_gq_stop_work() por si acaso) con mutex_lock() y mutex_unlock() en consecuencia, ya que estas funciones solo deben llamarse con mc_lock según sus declaraciones. [1] ERROR: KCSAN: carrera de datos en ipv6_mc_down / mld_ifc_work escribir en 0xffff88813a80c832 de 1 bytes por tarea 3771 en la CPU 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [en línea] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast .c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [en línea] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flag s+0x205/ 0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [en línea] __rtnl_newlink net/core/rtnetlink.c :3717 [en línea] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0 x1c /0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [en línea] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c :1910 ... escriba en 0xffff88813a80c832 de 1 bytes por tarea 22 en la CPU 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 Process_one_work kernel/workqueue.c:2627 [en línea] Process_scheduled_works+0x5b8/0xa30 kernel/ workqueue.c:2700 trabajador_thread+0x525/0x730 kernel/workqueue.c:2781 ... • https://git.kernel.org/stable/c/2d9a93b4902be6a5504b5941dd15e9cd776aadca https://git.kernel.org/stable/c/62b3387beef11738eb6ce667601a28fa089fa02c https://git.kernel.org/stable/c/380540bb06bb1d1b12bdc947d1b8f56cda6b5663 https://git.kernel.org/stable/c/3cc283fd16fba72e2cefe3a6f48d7a36b0438900 https://git.kernel.org/stable/c/3bb5849675ae1d592929798a2b37ea450879c855 https://git.kernel.org/stable/c/2e7ef287f07c74985f1bf2858bedc62bd9ebf155 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52612 – crypto: scomp - fix req->dst buffer overflow
https://notcve.org/view.php?id=CVE-2023-52612
In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: scomp - corrige el desbordamiento del búfer req->dst. El tamaño del búfer req->dst debe verificarse antes de copiar desde scomp_scratch->dst para evitar el problema de desbordamiento del búfer req->dst. . • https://git.kernel.org/stable/c/1ab53a77b772bf7369464a0e4fa6fd6499acf8f1 https://git.kernel.org/stable/c/1142d65c5b881590962ad763f94505b6dd67d2fe https://git.kernel.org/stable/c/e0e3f4a18784182cfe34e20c00eca11e78d53e76 https://git.kernel.org/stable/c/4518dc468cdd796757190515a9be7408adc8911e https://git.kernel.org/stable/c/a5f2f91b3fd7387e5102060809316a0f8f0bc625 https://git.kernel.org/stable/c/4df0c942d04a67df174195ad8082f6e30e7f71a5 https://git.kernel.org/stable/c/7d9e5bed036a7f9e2062a137e97e3c1e77fb8759 https://git.kernel.org/stable/c/71c6670f9f032ec67d8f4e3f8db4646bf •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52611 – wifi: rtw88: sdio: Honor the host max_req_size in the RX path
https://notcve.org/view.php?id=CVE-2023-52611
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: sdio: Honor the host max_req_size in the RX path Lukas reports skb_over_panic errors on his Banana Pi BPI-CM4 which comes with an Amlogic A311D (G12B) SoC and a RTL8822CS SDIO wifi/Bluetooth combo card. The error he observed is identical to what has been fixed in commit e967229ead0e ("wifi: rtw88: sdio: Check the HISR RX_REQUEST bit in rtw_sdio_rx_isr()") but that commit didn't fix Lukas' problem. Lukas found that disabling or limiting RX aggregation works around the problem for some time (but does not fully fix it). In the following discussion a few key topics have been discussed which have an impact on this problem: - The Amlogic A311D (G12B) SoC has a hardware bug in the SDIO controller which prevents DMA transfers. Instead all transfers need to go through the controller SRAM which limits transfers to 1536 bytes - rtw88 chips don't split incoming (RX) packets, so if a big packet is received this is forwarded to the host in it's original form - rtw88 chips can do RX aggregation, meaning more multiple incoming packets can be pulled by the host from the card with one MMC/SDIO transfer. This Depends on settings in the REG_RXDMA_AGG_PG_TH register (BIT_RXDMA_AGG_PG_TH limits the number of packets that will be aggregated, BIT_DMA_AGG_TO_V1 configures a timeout for aggregation and BIT_EN_PRE_CALC makes the chip honor the limits more effectively) Use multiple consecutive reads in rtw_sdio_read_port() and limit the number of bytes which are copied by the host from the card in one MMC/SDIO transfer. • https://git.kernel.org/stable/c/65371a3f14e73979958aea0db1e3bb456a296149 https://git.kernel.org/stable/c/5b5ddf21b978ec315cab9d9e7e6ac7374791a8c7 https://git.kernel.org/stable/c/0e9ffff72a0674cd6656314dbd99cdd2123a3030 https://git.kernel.org/stable/c/00384f565a91c08c4bedae167f749b093d10e3fe •