Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-pf: gestionar errores otx2_mbox_get_rsp en otx2_dcbnl.c. Agregar verificación de puntero de error después de llamar a otx2_mbox_get_rsp().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-pf: gestionar errores otx2_mbox_get_rsp en cn10k.c. Agregar verificación de puntero de error después de llamar a otx2_mbox_get_rsp().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-pf: gestionar errores otx2_mbox_get_rsp en otx2_flows.c. Añadiendo comprobación de puntero de error después de llamar a otx2_mbox_get_rsp().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-pf: gestionar errores otx2_mbox_get_rsp en otx2_ethtool.c. Agregar verificación de puntero de error después de llamar a otx2_mbox_get_rsp().

Se ha encontrado una vulnerabilidad clasificada como problemática en code-projects Hostel Management System 1.0. Este problema afecta a algunos procesos desconocidos del archivo /admin/registration.php. La manipulación del argumento fname/mname/lname provoca ataques de cross site scripting. El ataque puede iniciarse de forma remota.

Se ha encontrado una vulnerabilidad en code-projects Responsive Hotel Site 1.0 y se ha clasificado como crítica. Esta vulnerabilidad afecta a una funcionalidad desconocida del archivo /admin/newsletter.php. La manipulación del argumento eid conduce a una inyección SQL. El ataque se puede ejecutar de forma remota. El exploit se ha hecho público y puede utilizarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: proteger el trabajo de enlace caído para que no se ejecute después de que lgr freed el trabajo de enlace caído puede programarse antes de que lgr freed pero ejecutarse después de que lgr freed, lo que puede provocar un bloqueo. Por lo tanto, es necesario mantener una referencia antes de programar el trabajo de enlace caído y colocar la referencia después de que el trabajo se haya ejecutado o cancelado. La pila de llamadas de bloqueo relevante es la siguiente: corrupción de list_del. prev->next debería ser ffffb638c9c0fe20, pero era 0000000000000000 ------------[ cortar aquí ]------------ ¡ERROR del kernel en lib/list_debug.c:51! código de operación no válido: 0000 [#1] SMP NOPTI CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: cargado Contaminado: G #1 Nombre del hardware: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014 Cola de trabajo: eventos smc_link_down_work [smc] RIP: 0010:__list_del_entry_valid.cold+0x31/0x47 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 000000000000000 RDX: RSI: ffff94352091fc80 RDI: ffff94352091fc80 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0 FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000000400 PKRU: 55555554 Seguimiento de llamadas: rwsem_down_write_slowpath+0x17e/0x470 smc_link_down_work+0x3c/0x60 [smc] process_one_work+0x1ac/0x350 subproceso de trabajo+0x49/0x2f0 ? subproceso de rescate+0x360/0x360 kthread+0x118/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x1f/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: fix TSO DMA API usage burning cause oops Commit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data") movió la asignación de los miembros de tx_skbuff_dma[] para que sea posterior en stmmac_tso_xmit(). El buf (dma cookie) y len almacenados en esta estructura se pasan a dma_unmap_single() por stmmac_tx_clean(). La DMA API requiere que la dma cookie pasada a dma_unmap_single() sea la misma que el valor devuelto desde dma_map_single(). Sin embargo, al mover la asignación más tarde, este no es el caso cuando priv->dma_cap.addr64 > 32 como "des" es desplazado por proto_hdr_len. Esto causa problemas como: dwc-eth-dwmac 2490000.ethernet eth0: el mapa DMA de transmisión falló y con DMA_API_DEBUG habilitado: DMA-API: dwc-eth-dwmac 2490000.ethernet: el controlador del dispositivo intenta +liberar memoria DMA que no ha asignado [dirección del dispositivo=0x000000ffffcf65c0] [tamaño=66 bytes] Solucione esto manteniendo "des" como la cookie DMA original y use tso_des para pasar la cookie DMA de desplazamiento a stmmac_tso_allocator(). Los detalles completos de los fallos se pueden encontrar en: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panel: himax-hx83102: Agregar una comprobación para evitar la desreferencia de puntero NULL drm_mode_duplicate() podría devolver NULL debido a la falta de memoria, lo que luego invocará la desreferencia de puntero NULL. Agregue una comprobación para evitarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udmabuf: reparar pérdida de memoria en la última ruta de error export_udmabuf() En export_udmabuf(), si dma_buf_fd() falla porque la tabla FD está llena, ya se ha creado un dma_buf que posee el udmabuf; pero la gestión de errores en udmabuf_create() destruirá el udmabuf sin hacer nada con el dma_buf que lo contiene. Esto deja un dma_buf en la memoria que contiene un puntero colgante; aunque eso no parece conducir a nada malo excepto a una pérdida de memoria. Arréglelo moviendo la llamada dma_buf_fd() fuera de export_udmabuf() para que podamos darle un gestión de errores diferente. Tenga en cuenta que la forma de este código cambió mucho en el commit 5e72b2b41a21 ("udmabuf: convertir el controlador udmabuf para usar folios"); Pero la pérdida de memoria parece haber existido desde la introducción de udmabuf.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: netdevsim: fix nsim_pp_hold_write() nsim_pp_hold_write() tiene dos problemas: 1) Puede regresar con rtnl retenido, como lo encontró syzbot. 2) Su valor de retorno no propaga un error, si lo hay.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ionic: no double destroy workqueue Hay algunas rutas de gestión de errores de FW que pueden hacer que intentemos destruir la cola de trabajo más de una vez, así que asegurémonos de que estamos comprobando eso. El caso en el que esto apareció fue en un evento AER donde los controladores fueron llamados de tal manera que ionic_reset_prepare() y, por lo tanto, ionic_dev_teardown() fueron llamados dos veces seguidas. La segunda vez, la cola de trabajo ya estaba destruida y destroy_workqueue() se ahogó en el puntero wq defectuoso. No nos topamos con esto en las pruebas del controlador AER antes porque en ese momento no estábamos usando una cola de trabajo privada. Más tarde reemplazamos el uso de la cola de trabajo del sistema con nuestra propia cola de trabajo privada, pero no habíamos vuelto a ejecutar la prueba del controlador AER desde entonces.