Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ionic: Arreglar la cancelación del registro del notificador netdev en caso de error Si register_netdev() falla, el controlador filtra el notificador netdev. Solucione esto llamando a ionic_lif_unregister() en caso de error de register_netdev(). Esto también llamará a ionic_lif_unregister_phc() si ya se ha registrado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netdevsim: evitar entradas incorrectas del usuario en nsim_dev_health_break_write() Si se proporciona un recuento cero o uno grande, el kernel puede bloquearse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mscc: ocelot: se corrige el campo IFH SRC_PORT incorrecto en ocelot_ifh_set_basic() Los paquetes inyectados por la CPU deben tener un campo SRC_PORT igual al índice del módulo de puerto de la CPU en el bloque Analyzer (ocelot->num_phys_ports). el commit culpable copió la llamada ocelot_ifh_set_basic() incorrectamente desde ocelot_xmit_common() en net/dsa/tag_ocelot.c. En lugar de llamar con "x", llama con BIT_ULL(x), pero el campo no es una máscara de puerto, sino un índice de puerto único. [ nota al margen: esta es la deuda técnica de la duplicación de código :( ] El error solía ser silencioso y no parece tener otras manifestaciones visibles para el usuario, pero con los nuevos cambios en la librería de empaquetado, ahora falla ruidosamente de la siguiente manera: ------------[ cortar aquí ]------------ No se puede almacenar 0x40 dentro de los bits 46-43 - truncará sja1105 spi2.0: xmit timed out WARNING: CPU: 1 PID: 102 at lib/packing.c:98 __pack+0x90/0x198 sja1105 spi2.0: timed out polling for tstamp CPU: 1 UID: 0 PID: 102 Comm: felix_xmit Tainted: GWN 6.13.0-rc1-00372-gf706b85d972d-dirty #2605 Rastreo de llamadas: __pack+0x90/0x198 (P) __pack+0x90/0x198 (L) packing+0x78/0x98 ocelot_ifh_set_basic+0x260/0x368 ocelot_port_inject_frame+0xa8/0x250 felix_port_deferred_xmit+0x14c/0x258 kthread_worker_fn+0x134/0x350 kthread+0x114/0x138 La ruta del código pertenece al controlador switchdev de ocelot y al protocolo de etiqueta DSA secundaria de felix, ocelot-8021q. Aquí se ve con ocelot-8021q. El mensajero (packing) no es realmente el culpable, así que arregle el commit original en su lugar.

Se ha encontrado una vulnerabilidad clasificada como crítica en Codezips Event Management System 1.0. Se trata de una función desconocida del archivo /contact.php. La manipulación del argumento title provoca una inyección SQL. Es posible lanzar el ataque de forma remota. El exploit ha sido divulgado al público y puede ser utilizado.