CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26669 – net/sched: flower: Fix chain template offload
https://notcve.org/view.php?id=CVE-2024-26669
In the Linux kernel, the following vulnerability has been resolved: net/sched: flower: Fix chain template offload When a qdisc is deleted from a net device the stack instructs the underlying driver to remove its flow offload callback from the associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack then continues to replay the removal of the filters in the block for this driver by iterating over the chains in the block and invoking the 'reoffload' operation of the classifier being used. In turn, the classifier in its 'reoffload' operation prepares and emits a 'FLOW_CLS_DESTROY' command for each filter. However, the stack does not do the same for chain templates and the underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when a qdisc is deleted. This results in a memory leak [1] which can be reproduced using [2]. Fix by introducing a 'tmplt_reoffload' operation and have the stack invoke it with the appropriate arguments as part of the replay. Implement the operation in the sole classifier that supports chain templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}' command based on whether a flow offload callback is being bound to a filter block or being unbound from one. As far as I can tell, the issue happens since cited commit which reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains() in __tcf_block_put(). The order cannot be reversed as the filter block is expected to be freed after flushing all the chains. [1] unreferenced object 0xffff888107e28800 (size 2048): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[...... 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................ backtrace: [<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320 [<ffffffff81ab374e>] __kmalloc+0x4e/0x90 [<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0 [<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180 [<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280 [<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340 [<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0 [<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170 [<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0 [<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440 [<ffffffff83ac6270>] netlink_unicast+0x540/0x820 [<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0 [<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80 [<ffffffff8379d29a>] ___sys_sendmsg+0x13a/0x1e0 [<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0 [<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0 unreferenced object 0xffff88816d2c0400 (size 1024): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8..... 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff .. • https://git.kernel.org/stable/c/bbf73830cd48cff1599811d4f69c7cfd49c7b869 https://git.kernel.org/stable/c/9ed46144cff3598a5cf79955630e795ff9af5b97 https://git.kernel.org/stable/c/c04709b2cc99ae31c346f79f0211752d7b74df01 https://git.kernel.org/stable/c/32f2a0afa95fae0d1ceec2ff06e0e816939964b8 https://access.redhat.com/security/cve/CVE-2024-26669 https://bugzilla.redhat.com/show_bug.cgi?id=2272795 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: 7.1EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26668 – netfilter: nft_limit: reject configurations that cause integer overflow
https://notcve.org/view.php?id=CVE-2024-26668
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_limit: reject configurations that cause integer overflow Reject bogus configs where internal token counter wraps around. This only occurs with very very large requests, such as 17gbyte/s. Its better to reject this rather than having incorrect ratelimit. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nft_limit: rechazar configuraciones que causan desbordamiento de enteros Rechazar configuraciones falsas donde el contador de token interno se ajusta. Esto sólo ocurre con solicitudes muy grandes, como 17 gbytes/s. Es mejor rechazar esto en lugar de tener un límite de tasa incorrecto. • https://git.kernel.org/stable/c/d2168e849ebf617b2b7feae44c0c0baf739cb610 https://git.kernel.org/stable/c/79d4efd75e7dbecd855a3b8a63e65f7265f466e1 https://git.kernel.org/stable/c/bc6e242bb74e2ae616bfd2b250682b738e781c9b https://git.kernel.org/stable/c/9882495d02ecc490604f747437a40626dc9160d0 https://git.kernel.org/stable/c/00c2c29aa36d1d1827c51a3720e9f893a22c7c6a https://git.kernel.org/stable/c/c9d9eb9c53d37cdebbad56b91e40baf42d5a97aa https://access.redhat.com/security/cve/CVE-2024-26668 https://bugzilla.redhat.com/show_bug.cgi?id=2272797 • CWE-190: Integer Overflow or Wraparound •
CVSS: 7.1EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26665 – tunnels: fix out of bounds access when building IPv6 PMTU error
https://notcve.org/view.php?id=CVE-2024-26665
In the Linux kernel, the following vulnerability has been resolved: tunnels: fix out of bounds access when building IPv6 PMTU error If the ICMPv6 error is built from a non-linear skb we get the following splat, BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240 Read of size 4 at addr ffff88811d402c80 by task netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 ... kasan_report+0xd8/0x110 do_csum+0x220/0x240 csum_partial+0xc/0x20 skb_tunnel_check_pmtu+0xeb9/0x3280 vxlan_xmit_one+0x14c2/0x4080 vxlan_xmit+0xf61/0x5c00 dev_hard_start_xmit+0xfb/0x510 __dev_queue_xmit+0x7cd/0x32a0 br_dev_queue_push_xmit+0x39d/0x6a0 Use skb_checksum instead of csum_partial who cannot deal with non-linear SKBs. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: túneles: corrige el acceso fuera de los límites al compilar el error IPv6 PMTU Si el error ICMPv6 se genera a partir de un skb no lineal, obtenemos el siguiente símbolo, ERROR: KASAN: slab-out- fuera de los límites en do_csum+0x220/0x240 Lectura de tamaño 4 en la dirección ffff88811d402c80 por tarea netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 ... kasan_report+0xd8/0x110 do_csum+0x220 /0x240 csum_partial+0xc/0x20 skb_tunnel_check_pmtu+0xeb9/0x3280 vxlan_xmit_one+0x14c2/0x4080 vxlan_xmit+0xf61/0x5c00 dev_hard_start_xmit+0xfb/0x510 __dev_queue_xmit+0x7cd/0x32 a0 br_dev_queue_push_xmit+0x39d/0x6a0 Utilice skb_checksum en lugar de csum_partial, que no puede manejar SKB no lineales. A flaw was found in the Linux kernel. This issue occurs due to the improper handling of non-linear skbs (socket buffers) when calculating checksums for ICMPv6 PMTU error messages. This vulnerability can lead to out-of-bounds access, potentially causing memory corruption or crashes. • https://git.kernel.org/stable/c/4cb47a8644cc9eb8ec81190a50e79e6530d0297f https://git.kernel.org/stable/c/e77bf828f1ca1c47fcff58bdc26b60a9d3dfbe1d https://git.kernel.org/stable/c/d964dd1bc1452594b4207d9229c157d9386e5d8a https://git.kernel.org/stable/c/e37cde7a5716466ff2a76f7f27f0a29b05b9a732 https://git.kernel.org/stable/c/510c869ffa4068c5f19ff4df51d1e2f3a30aaac1 https://git.kernel.org/stable/c/7dc9feb8b1705cf00de20563b6bc4831f4c99dab https://git.kernel.org/stable/c/d75abeec401f8c86b470e7028a13fcdc87e5dd06 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-125: Out-of-bounds Read •
CVSS: 6.0EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26664 – hwmon: (coretemp) Fix out-of-bounds memory access
https://notcve.org/view.php?id=CVE-2024-26664
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix out-of-bounds memory access Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hwmon: (coretemp) Arreglar el acceso a memoria fuera de los límites Arreglar un error que pdata->cpu_map[] está configurado antes de la verificación de los límites. El problema podría surgir en sistemas con más de 128 núcleos por paquete. • https://git.kernel.org/stable/c/4f9dcadc55c21b39b072bb0882362c7edc4340bc https://git.kernel.org/stable/c/c00cdfc9bd767ee743ad3a4054de17aeb0afcbca https://git.kernel.org/stable/c/d9f0159da05df869071164edf0c6d7302efc5eca https://git.kernel.org/stable/c/30cf0dee372baf9b515f2d9c7218f905fddf3cdb https://git.kernel.org/stable/c/7108b80a542b9d65e44b36d64a700a83658c0b73 https://git.kernel.org/stable/c/d1de8e1ae924d9dc31548676e4a665b52ebee27e https://git.kernel.org/stable/c/93f0f4e846fcb682c3ec436e3b2e30e5a3a8ee6a https://git.kernel.org/stable/c/1eb74c00c9c3b13cb65e508c5d5a2f11a • CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26663 – tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()
https://notcve.org/view.php?id=CVE-2024-26663
In the Linux kernel, the following vulnerability has been resolved: tipc: Check the bearer type before calling tipc_udp_nl_bearer_add() syzbot reported the following general protection fault [1]: general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087] ... RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 ... Call Trace: <TASK> tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b The cause of this issue is that when tipc_nl_bearer_add() is called with the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called even if the bearer is not UDP. tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that the media_ptr field of the tipc_bearer has an udp_bearer type object, so the function goes crazy for non-UDP bearers. This patch fixes the issue by checking the bearer type before calling tipc_udp_nl_bearer_add() in tipc_nl_bearer_add(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tipc: verifique el tipo de portador antes de llamar a tipc_udp_nl_bearer_add() syzbot informó la siguiente falla de protección general [1]: falla de protección general, probablemente para la dirección no canónica 0xdffffc0000000010: 0000 [#1 ] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x00000000000000080-0x0000000000000087] ... RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 ... Seguimiento de llamadas: tipc_udp_ nl_bearer_add+ 0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink. c:1052 [en línea] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/ af_netlink.c:1341 [en línea] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0xd 5 /0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x 64 arco/x86/ Entry/common.c:52 [en línea] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b La causa de este problema es que cuando se llama a tipc_nl_bearer_add() con el atributo TIPC_NLA_BEARER_UDP_OPTS, tipc_udp_nl_bear er_añadir () se llama incluso si el portador no es UDP. tipc_udp_is_known_peer() llamado por tipc_udp_nl_bearer_add() supone que el campo media_ptr de tipc_bearer tiene un objeto de tipo udp_bearer, por lo que la función se vuelve loca para los portadores que no son UDP. Este parche soluciona el problema al verificar el tipo de portador antes de llamar a tipc_udp_nl_bearer_add() en tipc_nl_bearer_add(). • https://git.kernel.org/stable/c/ef20cd4dd1633987bcf46ac34ace2c8af212361f https://git.kernel.org/stable/c/24ec8f0da93b8a9fba11600be8a90f0d73fb46f1 https://git.kernel.org/stable/c/6f70f0b412458c622a12d4292782c8e92e210c2f https://git.kernel.org/stable/c/19d7314f2fb9515bdaac9829d4d8eb34edd1fe95 https://git.kernel.org/stable/c/c1701ea85ef0ec7be6a1b36c7da69f572ed2fd12 https://git.kernel.org/stable/c/3d3a5b31b43515b5752ff282702ca546ec3e48b6 https://git.kernel.org/stable/c/888e3524be87f3df9fa3c083484e4b62b3e3bb59 https://git.kernel.org/stable/c/0cd331dfd6023640c9669d0592bc0fd49 • CWE-20: Improper Input Validation •