Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: sch_api: corregir la ruta del error xa_insert() en tcf_block_get_ext() Este comando: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: la inserción dev del bloque falló: -EBUSY. falla porque el espacio de usuario solicita que se configure el mismo índice de bloque tanto para el ingreso como para el egreso. [nota al margen, no creo que haya fallado antes del commit 913b47d3424e ("net/sched: Introduce tc block netdev tracking infra"), porque este es un comando de un antiguo conjunto de notas mías que solían funcionar, pero por desgracia, no lo dividí científicamente] El problema no es que falle, sino que la segunda vez, falla de forma diferente (e irrecuperable): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [otra nota: el extack lo agregué yo con fines ilustrativos. El contexto del problema es que clsact_init() obtiene el mismo puntero &q->ingress_block que &q->egress_block, y dado que llamamos a tcf_block_get_ext() en ambos, "dev" se agregará al xarray block->ports dos veces, lo que hará que la operación falle: una vez a través del puntero del bloque de ingreso y otra vez a través del puntero del bloque de egreso. El problema en sí es que cuando xa_insert() falla, hemos emitido un comando FLOW_BLOCK_BIND a través de ndo_setup_tc(), pero la descarga nunca ve un FLOW_BLOCK_UNBIND correspondiente. Incluso corrigiendo la entrada incorrecta del usuario, aún no podemos recuperarnos: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: el bloque de flujo cb está ocupado. Básicamente, la única forma de recuperarse es reiniciar el sistema o desvincular y volver a vincular el controlador del dispositivo de red. Para corregir el error, debemos completar la ruta de desmontaje de error correcta que se omitió durante el movimiento del código y llamar a tcf_block_offload_unbind() cuando falla xa_insert(). [Última nota: fundamentalmente culpo a la convención de nombres de etiquetas en tcf_block_get_ext() por el error. Las etiquetas deben tener el nombre de lo que hacen, no de la ruta de error que las lleva a ellas. De esta manera, es obviamente incorrecto que dos etiquetas que apuntan al mismo código signifiquen que algo está mal, y verificar la corrección del código en el sitio de destino también es más fácil]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: dapm: corrección de error del verificador de los límites en dapm_widget_list_create La matriz de widgets en snd_soc_dapm_widget_list tiene un atributo __counted_by adjunto, que apunta a la variable num_widgets. Este atributo se utiliza en la comprobación de los límites y, si no se configura antes de que se llene la matriz, el sanitizador de los límites emitirá una advertencia o un pánico del kernel si se configura CONFIG_UBSAN_TRAP. Este parche establece el tamaño de la lista de widgets calculada con list_for_each como el valor inicial para num_widgets, ya que se utiliza para asignar memoria para la matriz. Se actualiza con el número real de elementos agregados después de que se llena la matriz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: dts: imx8ulp: corrija la cadena compatible con flexspi El flexspi en imx8ulp solo tiene 16 LUT, y el flexspi de imx8mm tiene 32 LUT, así que corrija la cadena compatible aquí, de lo contrario se encontrará con el siguiente error: [ 1.119072] ------------[ cortar aquí ]------------ [ 1.123926] ADVERTENCIA: CPU: 0 PID: 1 en drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Módulos vinculados en: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 No contaminado 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Nombre del hardware: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: 0 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 00000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 00000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 00000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 000000000000007a6 [ 1.238795] x2 : 000000000000000 x1 : 00000000000001ce x0 : 000000000ffffff92 [ 1.246267] Rastreo de llamadas: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] de_registro_dispositivo_spi+0x3b4/0x590 [ 1.322348] controlador_registro_spi+0x47c/0x754 [ 1.327181] controlador_registro_spi_devm+0x4c/0xa4 [ 1.332289] sonda_nxp_fspi+0x1cc/0x2b0 [ 1.336307] sonda_plataforma+0x68/0xc4 [ 1.340145] sonda_realmente+0xbc/0x29c [ 1.343893] dispositivo_sonda_controlador+0x78/0x12c [ 1.348457] dispositivo_sonda_controlador+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_para_cada_dispositivo+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] hacer_una_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ fin del seguimiento 000000000000000 ]--- [ 1.407908] ------------[ cortar aquí ]------------

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv4: ip_tunnel: Se corrige la advertencia de uso sospechoso de RCU en ip_tunnel_init_flow() Hay rutas de código desde las que se llama a la función sin mantener el bloqueo de lectura de RCU, lo que resulta en una advertencia de uso sospechoso de RCU [1]. Se soluciona utilizando l3mdev_master_upper_ifindex_by_index() que adquirirá el bloqueo de lectura de RCU antes de llamar a l3mdev_master_upper_ifindex_by_index_rcu(). [1] ADVERTENCIA: uso sospechoso de RCU 6.12.0-rc3-custom-gac8f72681cf2 #141 No contaminado ----------------------------- net/core/dev.c:876 ¡Lista de RCU recorrida en una sección que no es de lectura! Otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 1 bloqueo retenido por ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, en: rtnetlink_rcv_msg+0x377/0xf60 seguimiento de pila: CPU: 3 UID: 0 PID: 361 Comm: ip No contaminado 6.12.0-rc3-custom-gac8f72681cf2 #141 Nombre del hardware: Bochs Bochs, BIOS Bochs 01/01/2011 Seguimiento de llamadas: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 enlace de túnel ip_dev+0x72f/0xa00 nuevo enlace ip_tunnel+0x368/0x7a0 nuevo enlace ipgre+0x14c/0x170 nuevo enlace __rtnl+0x1173/0x19c0 nuevo enlace rtnl+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 unidifusión netlink+0x539/0x7f0 envío netlink_msg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 hacer_syscall_64+0xbb/0x1d0 entrada_SYSCALL_64_después_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mctp i2c: maneja dirección de encabezado NULL. daddr puede ser NULL si no hay ninguna entrada presente en la tabla de vecinos, en ese caso el paquete tx debe descartarse. saddr generalmente será configurado por el núcleo MCTP, pero verifica si es NULL en caso de que un paquete sea transmitido por un protocolo diferente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv4: ip_tunnel: Se corrige la advertencia de uso sospechoso de RCU en ip_tunnel_find() La tabla hash del túnel IP por netns está protegida por el mutex RTNL y ip_tunnel_find() solo se llama desde la ruta de control donde se toma el mutex. Agregue una expresión lockdep a hlist_for_each_entry_rcu() en ip_tunnel_find() para validar que se mantiene el mutex y silenciar la advertencia de uso sospechoso de RCU [1]. [1] ADVERTENCIA: uso sospechoso de RCU 6.12.0-rc3-custom-gd95d9a31aceb #139 No contaminado ----------------------------- net/ipv4/ip_tunnel.c:221 ¡Lista de RCU recorrida en la sección que no es de lectura! Otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 1 bloqueo retenido por ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, en: rtnetlink_rcv_msg+0x377/0xf60 seguimiento de pila: CPU: 12 UID: 0 PID: 362 Comm: ip No contaminado 6.12.0-rc3-custom-gd95d9a31aceb #139 Nombre del hardware: Bochs Bochs, BIOS Bochs 01/01/2011 Seguimiento de llamadas: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 hacer_syscall_64+0xbb/0x1d0 entrada_SYSCALL_64_después_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: resource,kexec: walk_system_ram_res_rev debe conservar los indicadores de recursos walk_system_ram_res_rev() descarta erróneamente los indicadores de recursos al pasar la información a la devolución de llamada. Esto hace que los sistemas con memoria IORESOURCE_SYSRAM_DRIVER_MANAGED tengan estos recursos seleccionados durante kexec para almacenar búferes kexec si esa memoria está ubicada por encima de la RAM normal del sistema. Esto conduce a un comportamiento indefinido después del reinicio. Si nunca se toca el búfer kexec, no sucede nada. Si se toca el búfer kexec, podría provocar un bloqueo (como a continuación) o un comportamiento indefinido. Probado en un sistema con expansores de memoria CXL con memoria administrada por el controlador, TPM habilitado y CONFIG_IMA_KEXEC=y. Agregar printk mostró que los indicadores se descartaban y, como resultado, la verificación de IORESOURCE_SYSRAM_DRIVER_MANAGED pasa. find_next_iomem_res: name(System RAM (kmem)) start(10000000000) end(1034fffffff) flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] ERROR: no se puede manejar el error de página para la dirección: ffff89834ffff000 [.] #PF: acceso de lectura del supervisor en modo kernel [.] #PF: error_code(0x0000) - página no presente [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:lista_de_mediciones_de_restauración_ima+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: enlace SATA inactivo (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Seguimiento de llamadas: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? plantilla_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] hacer_una_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? nueva_losa+0x12c/0x420 [.] ? nueva_losa+0x12c/0x420 [.] ? numero+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? analizar_args+0xd4/0x380 [.] ? analizar_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_desde_fork_asm+0x11/0x20 [.]

Una vulnerabilidad de ejecución remota de código (RCE) en el componente /inventory/doCptimpoptInventory de Weaver Ecology v9.* permite a los atacantes ejecutar código arbitrario mediante la inyección de un payload manipulada en el nombre de un archivo cargado.

Se descubrió que Weaver Ecology v9* contenía una vulnerabilidad de inyección SQL.

Se descubrió que Weaver Ecology v9.* contenía una vulnerabilidad de inyección SQL a través del componente /mobilemode/Action.jsp?invoker=com.weaver.formmodel.mobile.mec.servlet.MECAction&action=getFieldTriggerValue&searchField=*&fromTable=HrmResourceManager&whereClause=1%3d1&triggerCondition=1&expression=%3d&fieldValue=1.

Qualys descubrió que needrestart, antes de la versión 3.8, permite a los atacantes locales ejecutar código arbitrario como superusuario engañando a needrestart para que ejecute el intérprete de Python con una variable de entorno PYTHONPATH controlada por el atacante.

Qualys descubrió que needrestart, antes de la versión 3.8, permite a atacantes locales ejecutar código arbitrario como superusuario ganando una condición de ejecución y engañando a needrestart para que ejecute su propio intérprete de Python falso (en lugar del intérprete de Python real del sistema).