Page 364 of 2475 results (0.009 seconds)

CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0

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: 0

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: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: check for valid hw_pp in dpu_encoder_helper_phys_cleanup The commit 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback in case of YUV output") introduced a smatch warning about another conditional block in dpu_encoder_helper_phys_cleanup() which had assumed hw_pp will always be valid which may not necessarily be true. Lets fix the other conditional block by making sure hw_pp is valid before dereferencing it. Patchwork: https://patchwork.freedesktop.org/patch/574878/ En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/dpu: check for valid hw_pp en dpu_encoder_helper_phys_cleanup. El commit 8b45a26f2ba9 ("drm/msm/dpu: reserve bloques cdm para reescritura en caso de salida YUV") introdujo una coincidencia advertencia sobre otro bloque condicional en dpu_encoder_helper_phys_cleanup() que había asumido que hw_pp siempre será válido, lo que puede no ser necesariamente cierto. Arreglemos el otro bloque condicional asegurándonos de que hw_pp sea válido antes de eliminar la referencia a él. Remiendo: https://patchwork.freedesktop.org/patch/574878/ • https://git.kernel.org/stable/c/ae4d721ce10057a4aa9f0d253e0d460518a9ef75 https://git.kernel.org/stable/c/fb8bfc6ea3cd8c5ac3d35711d064e2f6646aec17 https://git.kernel.org/stable/c/79592a6e7bdc1d05460c95f891f5e5263a107af8 https://git.kernel.org/stable/c/eb4f56f3ff5799ca754ae6d811803a63fe25a4a2 https://git.kernel.org/stable/c/7f3d03c48b1eb6bc45ab20ca98b8b11be25f9f52 •

CVSS: 7.1EPSS: 0%CPEs: 6EXPL: 0

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: 0

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-&gt;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 •