Page 593 of 4237 results (0.013 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: mt76: mt7915: fix memleak when mt7915_unregister_device() mt7915_tx_token_put() should get call before mt76_free_pending_txwi(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mt76: mt7915: corrige memleak cuando mt7915_unregister_device() mt7915_tx_token_put() debería recibir una llamada antes que mt76_free_pending_txwi(). • https://git.kernel.org/stable/c/4e9e896f81932e337a93ad61cd3d9647571c4637 https://git.kernel.org/stable/c/f285dfb98562e8380101095d168910df1d07d8be https://git.kernel.org/stable/c/81483309ce861a9fa7835322787f68a443fea364 https://git.kernel.org/stable/c/d754c80ae82a662e692a82faad71b8c218cb7f52 https://git.kernel.org/stable/c/e9d32af478cfc3744a45245c0b126738af4b3ac4 •

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

In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: fix possible invalid register access Disable the interrupt and synchronze for the pending irq handlers to ensure the irq tasklet is not being scheduled after the suspend to avoid the possible invalid register access acts when the host pcie controller is suspended. [17932.910534] mt7921e 0000:01:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 21375 usecs [17932.910590] pcieport 0000:00:00.0: calling pci_pm_suspend+0x0/0x22c @ 18565, parent: pci0000:00 [17932.910602] pcieport 0000:00:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 8 usecs [17932.910671] mtk-pcie 11230000.pcie: calling platform_pm_suspend+0x0/0x60 @ 22783, parent: soc [17932.910674] mtk-pcie 11230000.pcie: platform_pm_suspend+0x0/0x60 returned 0 after 0 usecs ... 17933.615352] x1 : 00000000000d4200 x0 : ffffff8269ca2300 [17933.620666] Call trace: [17933.623127] mt76_mmio_rr+0x28/0xf0 [mt76] [17933.627234] mt7921_rr+0x38/0x44 [mt7921e] [17933.631339] mt7921_irq_tasklet+0x54/0x1d8 [mt7921e] [17933.636309] tasklet_action_common+0x12c/0x16c [17933.640754] tasklet_action+0x24/0x2c [17933.644418] __do_softirq+0x16c/0x344 [17933.648082] irq_exit+0xa8/0xac [17933.651224] scheduler_ipi+0xd4/0x148 [17933.654890] handle_IPI+0x164/0x2d4 [17933.658379] gic_handle_irq+0x140/0x178 [17933.662216] el1_irq+0xb8/0x180 [17933.665361] cpuidle_enter_state+0xf8/0x204 [17933.669544] cpuidle_enter+0x38/0x4c [17933.673122] do_idle+0x1a4/0x2a8 [17933.676352] cpu_startup_entry+0x24/0x28 [17933.680276] rest_init+0xd4/0xe0 [17933.683508] arch_call_rest_init+0x10/0x18 [17933.687606] start_kernel+0x340/0x3b4 [17933.691279] Code: aa0003f5 d503201f f953eaa8 8b344108 (b9400113) [17933.697373] ---[ end trace a24b8e26ffbda3c5 ]--- [17933.767846] Kernel panic - not syncing: Fatal exception in interrupt En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7921: corrige un posible acceso no válido al registro. Deshabilite la interrupción y la sincronización de los controladores irq pendientes para garantizar que el tasklet irq no se programe después de la suspensión para evitar el posible acceso no válido al registro. actúa cuando el controlador pcie del host está suspendido. [17932.910534] mt7921e 0000:01:00.0: pci_pm_suspend+0x0/0x22c devolvió 0 después de 21375 usos [17932.910590] pcieport 0000:00:00.0: llamando a pci_pm_suspend+0x0/0x22c @ 18565, padre: pci0000:00 [17932.910602] pcieport 0000: 00:00.0: pci_pm_suspend+0x0/0x22c devolvió 0 después de 8 usos [17932.910671] mtk-pcie 11230000.pcie: llamando a platform_pm_suspend+0x0/0x60 @ 22783, padre: soc [17932.910674] mtk-pcie 11230 000.pcie: plataforma_pm_suspend+0x0/ 0x60 devolvió 0 después de 0 usos... 17933.615352] x1: 00000000000d4200 x0: ffffff8269ca2300 [17933.620666] Rastreo de llamadas: [17933.623127] mt76_mmio_rr+0x28/0xf0 [mt76] [1 7933.627234] mt7921_rr+0x38/0x44 [mt7921e] [17933.631339] mt7921_irq_tasklet+ 0x54/0x1d8 [mt7921e] [17933.636309] tasklet_action_common+0x12c/0x16c [17933.640754] tasklet_action+0x24/0x2c [17933.644418] __do_softirq+0x16c/0x344 [17933.648 082] irq_exit+0xa8/0xac [17933.651224] planificador_ipi+0xd4/0x148 [17933.654890] handle_IPI +0x164/0x2d4 [17933.658379] gic_handle_irq+0x140/0x178 [17933.662216] el1_irq+0xb8/0x180 [17933.665361] cpuidle_enter_state+0xf8/0x204 [17933.669544] c puidle_enter+0x38/0x4c [17933.673122] do_idle+0x1a4/0x2a8 [17933.676352] cpu_startup_entry+0x24 /0x28 [17933.680276] rest_init+0xd4/0xe0 [17933.683508] arch_call_rest_init+0x10/0x18 [17933.687606] start_kernel+0x340/0x3b4 [17933.691279] Código: aa0003f5 d5032 01f f953eaa8 8b344108 (b9400113) [17933.697373] ---[ final de seguimiento a24b8e26ffbda3c5 ]- -- [17933.767846] Pánico del kernel: no se sincroniza: excepción fatal en la interrupción • https://git.kernel.org/stable/c/ffa1bf97425bd511b105ce769976e20a845a71e9 https://git.kernel.org/stable/c/b13cbc536990ff609afa878b6211cd6f6265ba60 https://git.kernel.org/stable/c/fe3fccde8870764ba3e60610774bd7bc9f8faeff •

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

In the Linux kernel, the following vulnerability has been resolved: powerpc/64: Fix the definition of the fixmap area At the time being, the fixmap area is defined at the top of the address space or just below KASAN. This definition is not valid for PPC64. For PPC64, use the top of the I/O space. Because of circular dependencies, it is not possible to include asm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size AREA at the top of the I/O space for fixmap and ensure during build that the size is big enough. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/64: corrige la definición del área de fixmap Por el momento, el área de fixmap está definida en la parte superior del espacio de direcciones o justo debajo de KASAN. Esta definición no es válida para PPC64. Para PPC64, utilice la parte superior del espacio de E/S. Debido a dependencias circulares, no es posible incluir asm/fixmap.h en asm/book3s/64/pgtable.h, así que defina un ÁREA de tamaño fijo en la parte superior del espacio de E/S para fixmap y asegúrese durante la compilación de que el El tamaño es lo suficientemente grande. • https://git.kernel.org/stable/c/265c3491c4bc8d40587996d6ee2f447a7ccfb4f3 https://git.kernel.org/stable/c/4b9fb2c9039a206d37f215936a4d5bee7b1bf9cd https://git.kernel.org/stable/c/abb07dc5e8b61ab7b1dde20dd73aa01a3aeb183f https://git.kernel.org/stable/c/a84df7c80bdac598d6ac9268ae578da6928883e8 https://git.kernel.org/stable/c/9ccba66d4d2aff9a3909aa77d57ea8b7cc166f3c https://access.redhat.com/security/cve/CVE-2021-47018 https://bugzilla.redhat.com/show_bug.cgi?id=2266594 • CWE-20: Improper Input Validation •

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

In the Linux kernel, the following vulnerability has been resolved: ath10k: Fix a use after free in ath10k_htc_send_bundle In ath10k_htc_send_bundle, the bundle_skb could be freed by dev_kfree_skb_any(bundle_skb). But the bundle_skb is used later by bundle_skb->len. As skb_len = bundle_skb->len, my patch replaces bundle_skb->len to skb_len after the bundle_skb was freed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath10k: corrige un use after free en ath10k_htc_send_bundle En ath10k_htc_send_bundle, el paquete_skb podría ser liberado por dev_kfree_skb_any(bundle_skb). Pero el paquete_skb lo utiliza más tarde el paquete_skb->len. Como skb_len = bundle_skb->len, mi parche reemplaza bundle_skb->len por skb_len después de que se liberó el paquete_skb. • https://git.kernel.org/stable/c/c8334512f3dd1b94844baca629f9bedca4271593 https://git.kernel.org/stable/c/8bb054fb336f4250002fff4e0b075221c05c3c65 https://git.kernel.org/stable/c/3b1ac40c6012140828caa79e592a438a18ebf71b https://git.kernel.org/stable/c/5e413c0831ff4700d1739db3fa3ae9f859744676 https://git.kernel.org/stable/c/8392df5d7e0b6a7d21440da1fc259f9938f4dec3 •

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

In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix RX consumer index logic in the error path. In bnxt_rx_pkt(), the RX buffers are expected to complete in order. If the RX consumer index indicates an out of order buffer completion, it means we are hitting a hardware bug and the driver will abort all remaining RX packets and reset the RX ring. The RX consumer index that we pass to bnxt_discard_rx() is not correct. We should be passing the current index (tmp_raw_cons) instead of the old index (raw_cons). This bug can cause us to be at the wrong index when trying to abort the next RX packet. It can crash like this: #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e #3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978 #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5 [exception RIP: bnxt_rx_pkt+237] RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213 RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000 RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000 RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bnxt_en: corrige la lógica del índice del consumidor RX en la ruta del error. • https://git.kernel.org/stable/c/a1b0e4e684e9c300b9e759b46cb7a0147e61ddff https://git.kernel.org/stable/c/8e302e8e10b05165ed21273539a1e6a83ab93e9e https://git.kernel.org/stable/c/46281ee85b651b0df686001651b965d17b8e2c67 https://git.kernel.org/stable/c/d2d055a554036b0240f296743942b8111fd4ce97 https://git.kernel.org/stable/c/aecbbae850ede49183fa0b73c7445531a47669cf https://git.kernel.org/stable/c/b1523e4ba293b2a32d9fabaf70c1dcaa6e3e2847 https://git.kernel.org/stable/c/4fcaad2b7dac3f16704f8118c7e481024ddbd3ed https://git.kernel.org/stable/c/e187ef83c04a5d23e68d39cfdff1a1931 •