Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: fsl-lpspi: corrige la fuga de referencia de PM en lpspi_prepare_xfer_hardware() pm_runtime_get_sync incrementará el contador de uso de PM incluso si falla. Olvidarse de poner en funcionamiento resultará en una fuga de referencia aquí. Solucionelo reemplazándolo con pm_runtime_resume_and_get para mantener el contador de uso equilibrado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: sa2ul - Reparar la pérdida de memoria de rxd Hay dos rutas de retorno de error que no liberan rxd y causan pérdidas de memoria. Arregla esto. Direcciones-Cobertura: ("Fuga de recursos")

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: sun8i-ss - Reparar pérdida de memoria del pad Parece que hay varias rutas de retorno de fallas que no parecen liberar el pad. Arregla esto. Direcciones-Cobertura: ("Fuga de recursos")

El modo En construcción/mantenimiento del complemento Acurax para WordPress es vulnerable a la exposición de información confidencial en versiones hasta la 2.6 incluida, a través de la función 'acx_csma_subscribe_ajax'. Esto puede permitir a atacantes autenticados extraer datos confidenciales, como nombres y direcciones de correo electrónico de visitantes suscritos.

El complemento Gestpay para WooCommerce para WordPress es vulnerable a la Cross-Site Request Forgery en todas las versiones hasta la 20221130 incluida. Esto se debe a una validación nonce faltante o incorrecta en la función 'ajax_set_default_card'. Esto hace posible que atacantes no autenticados establezcan el token de tarjeta predeterminado para un usuario a través de una solicitud falsificada, siempre que puedan engañar al administrador del sitio para que realice una acción como hacer clic en un enlace.

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.

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

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().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mt76: mt7615: corrige memleak cuando mt7615_unregister_device() mt7615_tx_token_put() debería recibir una llamada antes que mt76_free_pending_txwi().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: marvell: prestera: corrige el manejo de eventos del puerto en init Por alguna razón, puede haber una falla durante la creación de puertos si los eventos del puerto se manejan al mismo tiempo porque fw puede enviar el puerto inicial evento con estado inactivo. El bloqueo apunta a cancel_delayed_work(), que se llama cuando el puerto está inactivo. Actualmente no descubrí la causa real del problema, así que lo solucioné cancelando las estadísticas del puerto solo si el estado del puerto anterior estaba activo y funcionando. El siguiente es el fallo que se puede desencadenar: [28.311104] No se puede manejar la solicitud de paginación del kernel en la dirección virtual 000071775f776600 [28.319097] Información de cancelación de memoria: [28.321914] ESR = 0x96000004 [28.324996] EC = 0x25: DABT (EL actual), IL = 32 bits [ 28.330350] SET = 0, FnV = 0 [ 28.333430] EA = 0, S1PTW = 0 [ 28.336597] Información de cancelación de datos: [ 28.339499] ISV = 0, ISS = 0x00000004 [ 28.343362] CM = 0, WnR = 0 [ 28.346354] tabla de páginas de usuario: páginas de 4k, VA de 48 bits, pgdp=0000000100bf7000 [ 28.352842] [000071775f776600] pgd=00000000000000000, p4d=0000000000000000 [ 28.359695] Error interno: Ups: 96000004 [#1] PREEMPT SMP [ 28.365310] Módulos vinculados en: prestera_pci(+) prestera uio_pdrv_genirq [ 28.372005] CPU: 0 PID: 1291 Comm: kworker/0:1H No contaminado 5.11.0-rc4 #1 [ 28.378846] Nombre de hardware: DNI Placa AmazonGo1 A7040 (DT) [ 28.384283] Cola de trabajo : prestera_fw_wq prestera_fw_evt_work_fn [prestera_pci] [ 28.391413] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [ 28.397468] pc : get_work_pool+0x48/0x60 [ 28.401442] lr : try_to _grab_pending+0x6c/0x1b0 [28.406018] sp : ffff80001391bc60 [ 28.409358] x29: ffff80001391bc60 x28: 0000000000000000 [ 28.414725] x27: ffff000104fc8b40 x26: ffff80001127de88 [ 28.4200 89] x25: 0000000000000000 x24: ffff000106119760 [ 28.425452] x23: ffff00010775dd60 x22: ffff00010567e000 [ 28.430814] x21: 000000000000000000 x20: ffff80001391bcb0 [28.436175] x19: ffff00010775deb8 x18: 00000000000000c0 [ 28.441537] x17: 0000000000000000 x16: 000000008d9b0e88 [ 28.446898] x15: 00000000000000 01 x14: 00000000000002ba [ 28.452261] x13: 80a3002c00000002 x12: 00000000000005f4 [ 28.457622] x11: 0000000000000030 x10: 00000000000 0000c [28.462985] x9: 000000000000000c x8: 0000000000000030 [28.468346] x7: ffff800014400000 x6: ffff000106119758 [28.473708] x5: 00000000000000003 x4: ffff00010775dc60 [28.4790 68] x3: 0000000000000000 x2: 00000000000000060 [28.484429] x1: 000071775f776600 x0: ffff00010775deb8 [28.489791] Rastreo de llamadas: [28.492259] get_work_pool+ 0x48/ 0x60 [ 28.495874] cancel_delayed_work+0x38/0xb0 [ 28.500011] prestera_port_handle_event+0x90/0xa0 [prestera] [ 28.505743] prestera_evt_recv+0x98/0xe0 [prestera] [ 28.510683] prestera_fw _evt_work_fn+0x180/0x228 [prestera_pci] [ 28.516660] proceso_one_work+0x1e8/0x360 [ 28.520710] work_thread+0x44/0x480 [ 28.524412] kthread+0x154/0x160 [ 28.527670] ret_from_fork+0x10/0x38 [ 28.531290] Código: a8c17bfd d50323bf d65f03c0 92 78dc21 (f9400020) [28.537429] ---[ final de seguimiento 5eced933df3a080b ]---

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: vsock/virtio: paquetes libres en cola al cerrar el socket Según lo informado por syzbot [1], hay una pérdida de memoria al cerrar el socket. Resolvimos parcialmente este problema con el compromiso ac03046ece2b ("vsock/virtio: paquetes libres durante el lanzamiento del socket"), pero nos olvidamos de vaciar la cola RX cuando el trabajo programado cierra definitivamente el socket. Para evitar problemas futuros, usemos el nuevo virtio_transport_remove_sock() para drenar la cola RX antes de eliminar el socket de las listas af_vsock llamando a vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/mediatek: habilite siempre clk al reanudar. En mtk_iommu_runtime_resume habilite siempre clk, incluso si m4u_dom es nulo. De lo contrario, el cb 'suspender' podría desactivar el clk que ya está desactivado provocando la advertencia: [1.586104] infra_m4u ya desactivado [1.586133] ADVERTENCIA: CPU: 0 PID: 121 en drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8 [ 1.594391] mtk-iommu 10205000.iommu: enlazado 18001000.larb (ops mtk_smi_larb_component_ops) [ 1.598108] Módulos vinculados en: [ 1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 No contaminado 5.12.0 -rc5 #69 [ 1.609246] mtk-iommu 10205000.iommu: enlazado 14027000.larb (ops mtk_smi_larb_component_ops) [ 1.617487] Nombre del hardware: Google Elm (DT) [ 1.617491] Cola de trabajo: pm pm_runtime_work [ 1.620545] mtk-iomm u 10205000.iommu: encuadernado 19001000.larb (ops mtk_smi_larb_component_ops) [1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [1.659297] pc: clk_core_disable+0xb0/0xb8 [1.663475] lr: clk_core_disable+0xb0/0x b8 [1.667652] sp: ffff800011b9bbe0 [ 1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000 [ 1.676267] x27: ffff800011448000 x26: ffff8000100cfd98 [ 1.681574] x25: ffff800011b9 bd48 x24: 0000000000000000 [ 1.686882] x23: 0000000000000000 x22: ffff8000106fad90 [ 1.692189] x21: 0000000000000000a x20: ffff0000c004850 0 [1,697496] x19: ffff0000c0048500 x18: ffffffffffffffff [ 1.702804] x17: 0000000000000000 x16: 00000000000000000 [ 1.708112] x15: ffff800011460300 x14: ffffffffffe000 0 [ 1.713420] x13: ffff8000114602d8 x12: 0720072007200720 [ 1.718727] x11: 0720072007200720 x10: 0720072007200720 [ 1.724035] x9 : ffff800 011b9bbe0 x8: ffff800011b9bbe0 [ 1.729342] x7: 0000000000000009 x6: ffff8000114b8328 [1.734649] x5: 0000000000000000 x4: 00000000000000000 [1.739956] x3: 00000000ffff ffff x2: ffff800011460298 [1.745263] x1: 1af1d7de276f4500 x0: 0000000000000000 [1.750572] Rastreo de llamadas: [1.753010] clk_core_disable+0xb0/0xb8 [ 1.756840] clk_core_disable_lock+0x24/0x40 [ 1.761105] clk_disable+0x20/0x30 [ 1.764501] mtk_iommu_runtime_suspend+0x88/0xa8 [ 1.769114] pm_generic_runtime_suspend+0x2c/0x48 [ 1 .773815] __rpm_callback+0xe0/0x178 [ 1.777559] rpm_callback+0x24/0x88 [ 1.781041] rpm_suspend+0xdc/0x470 [ 1.784523] rpm_idle+0x12c/0x170 [ 1.787831] pm_runtime_work+0xa8/0xc0 [ 1.791573] Process_one_work+0x1e8/0x360 [ 1.795580] trabajador_thread+0x44/0x478 [ 1.799237] kthread+0x150/0x158 [ 1.802460] ret_from_fork+ 0x10/0x30 [1.806034] ---[ final de seguimiento 82402920ef64573b ]--- [ 1.810728] ------------[ cortar aquí ]------------ Además , ahora no necesitamos habilitar el reloj desde la función mtk_iommu_hw_init ya que ya está habilitado en el currículum.