Page 555 of 4611 results (0.017 seconds)

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. • https://git.kernel.org/stable/c/4f2673b3a2b6246729a1ff13b8945a040839dbd3 https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8 https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b https://access.redhat.com/security/cve/CVE-2024-26837 https://bugzilla.redhat.com/show_bug.cgi?id=2275580 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •

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

In the Linux kernel, the following vulnerability has been resolved: platform/x86: think-lmi: Fix password opcode ordering for workstations The Lenovo workstations require the password opcode to be run before the attribute value is changed (if Admin password is enabled). Tested on some Thinkpads to confirm they are OK with this order too. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: plataforma/x86: think-lmi: corrige el orden del código de operación de contraseña para las estaciones de trabajo Las estaciones de trabajo Lenovo requieren que se ejecute el código de operación de la contraseña antes de cambiar el valor del atributo (si la contraseña de administrador está habilitada). Probado en algunos Thinkpads para confirmar que también están de acuerdo con este pedido. • https://git.kernel.org/stable/c/640a5fa50a42b99bfa2a0ec51b4ea9591d9bd055 https://git.kernel.org/stable/c/2deb10a99671afda30f834e95e5b992a805bba6a https://git.kernel.org/stable/c/2bfbe1e0aed00ba51d58573c79452fada3f62ed4 https://git.kernel.org/stable/c/6f7d0f5fd8e440c3446560100ac4ff9a55eec340 •

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: set dormant flag on hook register failure We need to set the dormant flag again if we fail to register the hooks. During memory pressure hook registration can fail and we end up with a table marked as active but no registered hooks. On table/base chain deletion, nf_tables will attempt to unregister the hook again which yields a warn splat from the nftables core. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: establece el indicador inactivo en caso de error en el registro del enlace. Necesitamos configurar el indicador inactivo nuevamente si no logramos registrar los enlaces. Durante la presión de la memoria, el registro de ganchos puede fallar y terminamos con una tabla marcada como activa pero sin ganchos registrados. Al eliminar la tabla/cadena base, nf_tables intentará cancelar el registro del gancho nuevamente, lo que genera un símbolo de advertencia desde el núcleo de nftables. • https://git.kernel.org/stable/c/e10f661adc556c4969c70ddaddf238bffdaf1e87 https://git.kernel.org/stable/c/d9c4da8cb74e8ee6e58a064a3573aa37acf6c935 https://git.kernel.org/stable/c/179d9ba5559a756f4322583388b3213fe4e391b0 https://git.kernel.org/stable/c/ae4360cbd385f0d7a8a86d5723e50448cc6318f3 https://git.kernel.org/stable/c/31ea574aeca1aa488e18716459bde057217637af https://git.kernel.org/stable/c/664264a5c55bf97a9c571c557d477b75416199be https://git.kernel.org/stable/c/0c9302a6da262e6ab6a6c1d30f04a6130ed97376 https://git.kernel.org/stable/c/f2135bbf14949687e96cabb13d8a91ae3 •

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

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_flow_offload: release dst in case direct xmit path is used Direct xmit does not use it since it calls dev_queue_xmit() to send packets, hence it calls dst_release(). kmemleak reports: unreferenced object 0xffff88814f440900 (size 184): comm "softirq", pid 0, jiffies 4294951896 hex dump (first 32 bytes): 00 60 5b 04 81 88 ff ff 00 e6 e8 82 ff ff ff ff .`[............. 21 0b 50 82 ff ff ff ff 00 00 00 00 00 00 00 00 !.P............. backtrace (crc cb2bf5d6): [<000000003ee17107>] kmem_cache_alloc+0x286/0x340 [<0000000021a5de2c>] dst_alloc+0x43/0xb0 [<00000000f0671159>] rt_dst_alloc+0x2e/0x190 [<00000000fe5092c9>] __mkroute_output+0x244/0x980 [<000000005fb96fb0>] ip_route_output_flow+0xc0/0x160 [<0000000045367433>] nf_ip_route+0xf/0x30 [<0000000085da1d8e>] nf_route+0x2d/0x60 [<00000000d1ecd1cb>] nft_flow_route+0x171/0x6a0 [nft_flow_offload] [<00000000d9b2fb60>] nft_flow_offload_eval+0x4e8/0x700 [nft_flow_offload] [<000000009f447dbb>] expr_call_ops_eval+0x53/0x330 [nf_tables] [<00000000072e1be6>] nft_do_chain+0x17c/0x840 [nf_tables] [<00000000d0551029>] nft_do_chain_inet+0xa1/0x210 [nf_tables] [<0000000097c9d5c6>] nf_hook_slow+0x5b/0x160 [<0000000005eccab1>] ip_forward+0x8b6/0x9b0 [<00000000553a269b>] ip_rcv+0x221/0x230 [<00000000412872e5>] __netif_receive_skb_one_core+0xfe/0x110 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_flow_offload: libera dst en caso de que se use la ruta de xmit directa Direct xmit no la usa ya que llama a dev_queue_xmit() para enviar paquetes, por lo tanto llama a dst_release(). informes kmemleak: objeto sin referencia 0xffff88814f440900 (tamaño 184): comm "softirq", pid 0, jiffies 4294951896 volcado hexadecimal (primeros 32 bytes): 00 60 5b 04 81 88 ff ff 00 e6 e8 82 ff ff ff ff .`[.. ........... 21 0b 50 82 ff ff ff ff 00 00 00 00 00 00 00 00 !.P................. retroceso (crc cb2bf5d6): [ &lt;000000003ee17107&gt;] kmem_cache_alloc+0x286/0x340 [&lt;0000000021a5de2c&gt;] dst_alloc+0x43/0xb0 [&lt;00000000f0671159&gt;] rt_dst_alloc+0x2e/0x190 [&lt;00000000fe50 92c9&gt;] __mkroute_output+0x244/0x980 [&lt;000000005fb96fb0&gt;] ip_route_output_flow+0xc0/0x160 [ &lt;0000000045367433&gt;] nf_ip_route+0xf/0x30 [&lt;0000000085da1d8e&gt;] nf_route+0x2d/0x60 [&lt;00000000d1ecd1cb&gt;] nft_flow_route+0x171/0x6a0 [nft_flow_offload] 0000d9b2fb60&gt;] nft_flow_offload_eval+0x4e8/0x700 [nft_flow_offload] [&lt;000000009f447dbb&gt;] expr_call_ops_eval+0x53/0x330 [nf_tables] [&lt;00000000072e1be6&gt;] nft_do_chain+0x17c/0x840 [nf_tables] [&lt;00000000d0551029&gt;] nft_do_chain_inet+0xa1/0x210 [nf_tables] [ &lt;0000000097c9d5c6&gt;] nf_hook_slow+0x5b/0x160 [&lt;0000000005eccab1&gt;] ip_forward +0x8b6/0x9b0 [&lt;00000000553a269b&gt;] ip_rcv+0x221/0x230 [&lt;00000000412872e5&gt;] __netif_receive_skb_one_core+0xfe/0x110 • https://git.kernel.org/stable/c/fa502c86566680ac62bc28ec883a069bf7a2aa5e https://git.kernel.org/stable/c/9256ab9232e35a16af9c30fa4e522e6d1bd3605a https://git.kernel.org/stable/c/2d17cf10179a7de6d8f0128168b84ad0b4a1863f https://git.kernel.org/stable/c/8762785f459be1cfe6fcf7285c123aad6a3703f0 https://git.kernel.org/stable/c/13b57b5cd591d5b22f9bbf047b2922967de411f3 https://git.kernel.org/stable/c/a6cafdb49a7bbf4a88367db209703eee6941e023 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix memory leak in dm_sw_fini() After destroying dmub_srv, the memory associated with it is not freed, causing a memory leak: unreferenced object 0xffff896302b45800 (size 1024): comm "(udev-worker)", pid 222, jiffies 4294894636 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 6265fd77): [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340 [<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [<ffffffffc0ea4e55>] dm_sw_init+0x15/0x2b0 [amdgpu] [<ffffffffc0ba8557>] amdgpu_device_init+0x1417/0x24e0 [amdgpu] [<ffffffffc0bab285>] amdgpu_driver_load_kms+0x15/0x190 [amdgpu] [<ffffffffc0ba09c7>] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [<ffffffff9968fd1e>] local_pci_probe+0x3e/0x90 [<ffffffff996918a3>] pci_device_probe+0xc3/0x230 [<ffffffff99805872>] really_probe+0xe2/0x480 [<ffffffff99805c98>] __driver_probe_device+0x78/0x160 [<ffffffff99805daf>] driver_probe_device+0x1f/0x90 [<ffffffff9980601e>] __driver_attach+0xce/0x1c0 [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0 [<ffffffff99804822>] bus_add_driver+0x112/0x210 [<ffffffff99807245>] driver_register+0x55/0x100 [<ffffffff990012d1>] do_one_initcall+0x41/0x300 Fix this by freeing dmub_srv after destroying it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corrige la pérdida de memoria en dm_sw_fini() Después de destruir dmub_srv, la memoria asociada a él no se libera, lo que provoca una pérdida de memoria: objeto sin referencia 0xffff896302b45800 (tamaño 1024) : comm "(udev-worker)", pid 222, sjiffies 4294894636 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........... ..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso (crc 6265fd77): [] kmalloc_trace+ 0x29d/0x340 [] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [] dm_sw_init+0x15/0x2b0 [amdgpu] [] 1417/0x24e0 [amdgpu] [] amdgpu_driver_load_kms+0x15 /0x190 [amdgpu] [] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [] local_pci_probe+0x3e/0x90 [] pci_device_probe+0xc3/0x230 [ ] realmente_probe+0xe2/0x480 [&lt; ffffffff99805c98&gt;] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] v+0x70/0xc0 [] bus_add_driver+0x112/0x210 [&lt; ffffffff99807245&gt;] driver_register+0x55/0x100 [] do_one_initcall+0x41/0x300 Solucione este problema liberando dmub_srv después de destruirlo. • https://git.kernel.org/stable/c/743b9786b14ae0d7d13b3782dccad158e577e9bb https://git.kernel.org/stable/c/b49b022f7dfce85eb77d0d987008fde5c01d7857 https://git.kernel.org/stable/c/33f649f1b1cea39ed360e6c12bba4fac83118e6e https://git.kernel.org/stable/c/58168005337eabef345a872be3f87d0215ff3b30 https://git.kernel.org/stable/c/10c6b90e975358c17856a578419dc449887899c2 https://git.kernel.org/stable/c/541e79265ea7e339a7c4a462feafe9f8f996e04b https://git.kernel.org/stable/c/bae67893578d608e35691dcdfa90c4957debf1d3 https://lists.debian.org/debian-lts-announce/2024/06/ •