Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: ufs: corrige un punto muerto en el controlador de errores Se ha observado el siguiente punto muerto en una configuración de prueba: - Todas las etiquetas asignadas - El controlador de errores SCSI llama a ufshcd_eh_host_reset_handler() - ufshcd_eh_host_reset_handler( ) las colas funcionan que llaman a ufshcd_err_handler() - ufshcd_err_handler() se bloquea de la siguiente manera: Cola de trabajo: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt Rastreo de llamadas: __switch_to+0x298/0x5d8 __schedule+0x6cc/0xa94 Schedule+0x12c/0x298 get_tag+0x210/0x480 __blk_mq_alloc_request+0x1c8/ 0x284 blk_get_request+0x74/0x134 ufshcd_exec_dev_cmd+0x68/0x640 ufshcd_verify_dev_init+0x68/0x35c ufshcd_probe_hba+0x12c/0x1cb8 ufshcd_host_reset_and_restore+0x88/0x254 _reset_and_restore+0xd0/0x354 ufshcd_err_handler+0x408/0xc58 proceso_one_work+0x24c/0x66c trabajador_thread+0x3e8/0xa4c kthread+0x150/ 0x1b4 ret_from_fork+0x10/0x30 Solucione este bloqueo haciendo que ufshcd_exec_dev_cmd() asigne una solicitud reservada.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/fixmap: corrige la advertencia de depuración de VM al desasignar La desasignación de una entrada de fixmap se realiza llamando a __set_fixmap() con FIXMAP_PAGE_CLEAR como indicadores. Hoy, powerpc __set_fixmap() llama a map_kernel_page(). map_kernel_page() no está contento cuando se le llama por segunda vez para la misma página. ADVERTENCIA: CPU: 0 PID: 1 en arch/powerpc/mm/pgtable.c:194 set_pte_at+0xc/0x1e8 CPU: 0 PID: 1 Comm: swapper No contaminado 5.16.0-rc3-s3k-dev-01993-g350ff07feb7d- sucio #682 NIP: c0017cd4 LR: c00187f0 CTR: 00000010 REGS: e1011d50 TRAP: 0700 No contaminado (5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty) MSR: 00029032 CR: 42000208 XER: 00000000 GPR00: c0165fec e1011e10 c14c0000 c0ee2550 ff800000 c0f3d000 00000000 c001686c GPR08: 00001000 b00045a9 00000001 c 0f58460 c0f50000 00000000 c0007e10 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 00000000 00000000 c0ee2550 00000000 c0f57000 00000ff8 00000000 ff800000 PIN [c0017cd4 ] set_pte_at+0xc/0x1e8 LR [c00187f0] map_kernel_page+0x9c/0x100 Seguimiento de llamadas: [e1011e10] [c0736c68] vsnprintf+0x358/0x6c8 (no confiable) [e1011e30] [c0165fec] x44 [e1011e40] [c0c13bdc] early_iounmap +0x11c/0x170 [e1011e70] [c0c06cb0] ioremap_legacy_serial_console+0x88/0xc0 [e1011e90] [c0c03634] do_one_initcall+0x80/0x178 [e1011ef0] [c0c0385c] kernel_init_freeable+0xb4 /0x250 [e1011f20] [c0007e34] kernel_init+0x24/0x140 [e1011f30 ] [c0016268] ret_from_kernel_thread+0x5c/0x64 Volcado de instrucciones: 7fe3fb78 48019689 80010014 7c630034 83e1000c 5463d97e 7c0803a6 38210010 4e800020 0 712a0001 41820008 <0fe00000> 9421ffe0 93e1001c 48000030 Implemente unmap_kernel_page() que borra un pte existente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sunrpc: corrige fugas de recuento de referencias en rpc_sysfs_xprt_state_change Los problemas de fugas de recuento tienen lugar en una ruta de manejo de errores. Cuando el tercer argumento buf no coincide con "fuera de línea", "en línea" o "eliminar", la función simplemente devuelve -EINVAL y se olvida de disminuir el recuento de referencias de un objeto rpc_xprt y un objeto rpc_xprt_switch aumentado en rpc_sysfs_xprt_kobj_get_xprt() y rpc_sysfs_xprt_kobj_get_xprt_switch (), lo que provoca fugas en el recuento de referencias de ambos objetos no utilizados. Solucione este problema saltando a la ruta de manejo de errores etiquetada con out_put cuando buf no coincida con "fuera de línea", "en línea" o "eliminar".

En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: xprtrdma: corrige derefs de puntero en casos de error de rpcrdma_ep_create Si hay fallos entonces no debemos dejar los punteros no NULL con el valor de error, de lo contrario `rpcrdma_ep_destroy` se confunde y prueba free ellos, lo que resulta en un Ups.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: ptdma: corrige la ruta de manejo de errores en pt_core_init() Para liberar recursos correctamente en la ruta de manejo de errores de pt_core_init(), se deben cambiar 2 goto. De lo contrario, algunos recursos se filtrarán e intentaremos liberar cosas que aún no se han asignado. También mueva un dev_err() a un lugar donde sea más significativo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Controladores: hv: vmbus: corrige la pérdida de memoria en vmbus_add_channel_kobj kobject_init_and_add() toma referencia incluso cuando falla. ¿Según el documento de kobject_init_and_add()? Si esta función devuelve un error, se debe llamar a kobject_put() para limpiar adecuadamente la memoria asociada con el objeto. Solucione la pérdida de memoria llamando a kobject_put().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: parsers: qcom: Corrige la falta de espacio libre para pparts en la limpieza Mtdpart no libera pparts cuando se declara una función de limpieza. Agregue piezas libres faltantes en la función de limpieza para que smem arregle la fuga.

El complemento RSS Aggregator – RSS Import, News Feeds, Feed to Post, and Autoblogging para WordPress es vulnerable a modificaciones no autorizadas de datos debido a una falta de verificación de capacidad en las funciones 'wprss_activate_feed_source' y 'wprss_pause_feed_source' en todas las versiones hasta e incluyendo, 23.04.11. Esto hace posible que los atacantes autenticados, con acceso a nivel de suscriptor y superior, activen o detengan los canales RSS existentes.

El complemento HUSKY – Products Filter Professional para WooCommerce para WordPress es vulnerable a la inyección SQL basada en tiempo a través del parámetro 'woof_author' en todas las versiones hasta la 1.3.6 incluida debido a un escape insuficiente en el parámetro proporcionado por el usuario y a la falta de suficiente preparación de la consulta SQL existente. Esto hace posible que atacantes no autenticados agreguen consultas SQL adicionales a consultas ya existentes que pueden usarse para extraer información confidencial de la base de datos.

Existe una vulnerabilidad de inyección SQL en Apache Superset debido a una neutralización inadecuada de elementos especiales utilizados en los comandos SQL. Específicamente, ciertas funciones específicas del motor no están marcadas, lo que permite a los atacantes eludir la autorización SQL de Apache Superset. Para mitigar esto, se introdujo una nueva clave de configuración denominada DISALLOWED_SQL_FUNCTIONS. Esta clave no permite el uso de las siguientes funciones de PostgreSQL: versión, query_to_xml, inet_server_addr e inet_client_addr. Se pueden agregar funciones adicionales a esta lista para una mayor protección. Este problema afecta a Apache Superset: antes de 4.0.2. Se recomienda a los usuarios actualizar a la versión 4.0.2, que soluciona el problema.

El complemento Web and WooCommerce Addons for WPBakery Builder para WordPress son vulnerables a modificaciones no autorizadas de la configuración del complemento debido a una falta de verificación de capacidad en varias funciones del complemento en todas las versiones hasta la 1.4.5 incluida. Esto hace posible que los atacantes autenticados, con acceso a nivel de suscriptor y superior, cambien algunas de las configuraciones del complemento.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: USB: core: corrige la ejecución al no sobrescribir udev->descriptor en hub_port_init() Syzbot informó una lectura fuera de los límites en sysfs.c:read_descriptors(): ERROR: KASAN : slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Lectura de tamaño 8 en addr ffff88801e78b8c8 por tarea udevd/5011 CPU: 0 PID: 5011 Comm: udevd No contaminado 6.4. 0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/05/2023 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xd9 /0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [en línea] kasan_report+0x11c/0x130 mm/kasan/report .c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Asignado por la tarea 758: ... __do_kmalloc_node mm/slab_common.c:966 [en línea] __kmalloc+0x5e/0x190 mm/slab_common .c:979 kmalloc include/linux/slab.h:563 [en línea] kzalloc include/linux/slab.h:680 [en línea] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb /core/hub.c:2407 [en línea] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 Según lo analizado por Khazhy Kumykov, la causa de este error es una ejecución entre read_descriptors() y hub_port_init(): La primera rutina usa un campo en udev->descriptor, sin esperar que cambie, mientras que la segunda lo sobrescribe. Antes de commit 45bf39f8df7f ("USB: core: No mantener bloqueado el dispositivo mientras lee el archivo sysfs de "descriptores") esta ejecución no podía ocurrir porque las rutinas eran mutuamente excluyentes gracias al bloqueo del dispositivo. Quitar ese bloqueo de read_descriptors() lo expuso a la ejecución. La mejor manera de corregir el error es evitar que hub_port_init() cambie el descriptor udev->una vez que udev se haya inicializado y registrado. Los controladores esperan que los descriptores almacenados en el kernel sean inmutables; No debemos socavar esta expectativa. De hecho, este cambio debería haberse realizado hace mucho tiempo. Entonces ahora hub_port_init() tomará un argumento adicional, especificando un búfer en el cual almacenar el descriptor del dispositivo que lee. (Si udev aún no se ha inicializado, el puntero del búfer será NULL y luego hub_port_init() almacenará el descriptor del dispositivo en udev como antes). Esto elimina la ejecución de datos responsable de la lectura fuera de los límites. Los cambios en hub_port_init() parecen más extensos de lo que realmente son, debido a los cambios de sangría resultantes de un intento de evitar escribir en otras partes de la estructura usb_device después de que se haya inicializado. Se deben realizar cambios similares en el código que lee el descriptor BOS, pero eso se puede manejar en un parche separado más adelante. Este parche es suficiente para corregir el error encontrado por syzbot.