Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

No hay vulnerabilidades nuevas para los productos a los que está suscrito.

Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:

Vulnerabilidad en la carga de un archivo en el host en SonicWall Email Security (CVE-2021-20022)
Severidad: ALTA
Fecha de publicación: 09/04/2021
Fecha de última actualización: 10/11/2025
SonicWall Email Security versión 10.0.9.x, contiene una vulnerabilidad que permite a un atacante autenticado posteriormente cargar un archivo arbitrario en el host remoto
Vulnerabilidad en el envío de una petición HTTP en SonicWall Email Security (CVE-2021-20021)
Severidad: CRÍTICA
Fecha de publicación: 09/04/2021
Fecha de última actualización: 10/11/2025
Una vulnerabilidad en SonicWall Email Security versión 10.0.9.x, permite a un atacante crear una cuenta administrativa mediante el envío de una petición HTTP diseñada en el host remoto
Vulnerabilidad en kernel de Linux (CVE-2022-49818)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mISDN: corregir el uso incorrecto de put_device() en mISDN_register_device() No debemos liberar la referencia de put_device() antes de llamar a device_initialize().
Vulnerabilidad en kernel de Linux (CVE-2022-49819)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeon_ep: se corrige una posible fuga de memoria en octep_device_setup(). Cuando se producen errores unsupported_dev e init de mbox, no se liberan oct->conf ni iounmap() de oct->mmio[i].hw_addr. Esto causaría un problema de fuga de memoria. Se añaden kfree() para oct->conf e iounmap() para oct->mmio[i].hw_addr en los errores unsupported_dev e init de mbox para solucionar el problema.
Vulnerabilidad en kernel de Linux (CVE-2022-49820)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mctp i2c: no cuente las claves no utilizadas o no válidas para la liberación del flujo Actualmente estamos alcanzando el WARN_ON en mctp_i2c_flow_release: if (midev->release_count > midev->i2c_lock_count) { WARN_ONCE(1, "release count overflow"); Esto puede ser alcanzado si expiramos un flujo antes de enviar el primer paquete que contiene, ya que no estaremos emparejando el incremento de release_count (realizado en la liberación del flujo) con la operación de bloqueo i2c (solo se realiza en TX real). Para corregir esto, solo libere un flujo si lo hemos encontrado previamente (es decir, dev_flow_state no indica NUEVO), ya que marcaremos el flujo como ACTIVO al mismo tiempo que contabilizamos la operación de bloqueo i2c. También necesitamos agregar un estado de flujo INVÁLIDO, para indicar cuándo hemos realizado la liberación.
Vulnerabilidad en kernel de Linux (CVE-2022-49821)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mISDN: corrige posible pérdida de memoria en mISDN_dsp_element_register() Después de la confirmación 1fa5ae857bb1 ("núcleo del controlador: deshacerse de la matriz de cadenas bus_id del dispositivo struct"), el nombre del dispositivo se asigna dinámicamente, use put_device() para renunciar a la referencia, de modo que el nombre se pueda liberar en kobject_cleanup() cuando refcount sea 0. La 'entrada' se liberará en mISDN_dsp_dev_release(), por lo que se elimina kfree(). list_del() se llama en mISDN_dsp_dev_release(), por lo que necesita inicializarse.
Vulnerabilidad en kernel de Linux (CVE-2022-49822)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: Se corrige la fuga de conexiones al fallar la configuración de Tlink. Si la configuración de Tlink falla, se pierden las conexiones y se produce una fuga de referencia del módulo, ya que el kthread de cifsd no finaliza. También se filtra la información de fscache, y en el siguiente montaje con fsc, se mostrarán los siguientes errores: CIFS: La clave del volumen de caché ya está en uso (cifs,127.0.0.1:445,TEST). Revisemos el resultado de la configuración de Tlink y realicemos una limpieza.
Vulnerabilidad en kernel de Linux (CVE-2022-49823)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: libata-transport: corrección del manejo de errores en ata_tdev_add(). En ata_tdev_add(), no se comprueba el valor de retorno de transport_add_device(). Como resultado, se genera una referencia nula al eliminar el módulo, ya que se llama a transport_remove_device() para eliminar el dispositivo no añadido. No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 00000000000000d0 CPU: 13 PID: 13603 Comm: rmmod Kdump: cargado Tainted: GW 6.1.0-rc3+ #36 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x3a0 lr : device_del+0x44/0x3a0 Rastreo de llamadas: device_del+0x48/0x3a0 attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tdev_delete+0x24/0x50 [libata] ata_tlink_delete+0x40/0xa0 [libata] ata_tport_delete+0x2c/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Para solucionar este problema, verifique y gestione el valor de retorno de transport_add_device() en ata_tdev_add(). En la ruta de error, se llama a device_del() para eliminar el dispositivo añadido previamente en esta función, y ata_tdev_free() para liberar ata_dev.
Vulnerabilidad en kernel de Linux (CVE-2022-49824)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: libata-transport: corrección del manejo de errores en ata_tlink_add(). En ata_tlink_add(), no se comprueba el valor de retorno de transport_add_device(). Como resultado, se genera una referencia nula al eliminar el módulo, ya que se llama a transport_remove_device() para eliminar el dispositivo no añadido. No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 00000000000000d0 CPU: 33 PID: 13850 Comm: rmmod Kdump: cargado Tainted: GW 6.1.0-rc3+ #12 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x39c lr : device_del+0x44/0x39c Rastreo de llamadas: device_del+0x48/0x39c attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tlink_delete+0x88/0xb0 [libata] ata_tport_delete+0x2c/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Solucione esto verificando y manejando el valor de retorno de transport_add_device() en ata_tlink_add().
Vulnerabilidad en kernel de Linux (CVE-2022-49825)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: libata-transport: corrección del manejo de errores en ata_tport_add(). En ata_tport_add(), no se comprueba el valor de retorno de transport_add_device(). Como resultado, se genera una referencia nula al eliminar el módulo, ya que se llama a transport_remove_device() para eliminar el dispositivo no añadido. No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 00000000000000d0 CPU: 12 PID: 13605 Comm: rmmod Kdump: cargado Tainted: GW 6.1.0-rc3+ #8 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x39c lr : device_del+0x44/0x39c Rastreo de llamadas: device_del+0x48/0x39c attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tport_delete+0x34/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Solucione esto verificando y manejando el valor de retorno de transport_add_device() en ata_tport_add().
Vulnerabilidad en kernel de Linux (CVE-2022-49826)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: libata-transport: corrección de un error doble de ata_host_put() en ata_tport_add(). En la ruta de error de ata_tport_add(), al llamar a put_device(), se llama a ata_tport_release(), lo que resta el recuento de referencias de 'ap->host'. A continuación, se vuelve a llamar a ata_host_put(), el recuento de referencias se reduce a 0 y se llama a ata_host_release(), liberando todos los puertos y estableciéndolos en nulo. Al desvincular el dispositivo tras un fallo, se llama a ata_host_stop() para liberar los recursos, lo que genera un error null-ptr-deref(), ya que todos los puertos están liberados y en nulo. No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000008 CPU: 7 PID: 18671 Comm: modprobe Kdump: cargado Contaminado: GE 6.1.0-rc3+ #8 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ata_host_stop+0x3c/0x84 [libata] lr : release_nodes+0x64/0xd0 Rastreo de llamadas: ata_host_stop+0x3c/0x84 [libata] release_nodes+0x64/0xd0 devres_release_all+0xbc/0x1b0 device_unbind_cleanup+0x20/0x70 really_probe+0x158/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120 __driver_attach+0xb4/0x220 bus_for_each_dev+0x78/0xdc driver_attach+0x2c/0x40 bus_add_driver+0x184/0x240 driver_register+0x80/0x13c __pci_register_driver+0x4c/0x60 ahci_pci_driver_init+0x30/0x1000 [ahci] Solucione esto eliminando ata_host_put() redundante en la ruta de error.
Vulnerabilidad en kernel de Linux (CVE-2022-49827)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: Se corrige la posible desreferencia PTR nula en la llamada drm_vblank_destroy_worker(). drm_vblank_init() llama a drmm_add_action_or_reset() con la acción drm_vblank_init_release(). Si __drmm_add_action() falla, se llamará directamente a drm_vblank_init_release() con el vblank cuyo trabajador sea NULL. Como resultado, se producirá una desreferencia PTR nula en kthread_destroy_worker(). Se añade la comprobación de valores NULL antes de llamar a drm_vblank_destroy_worker(). ERROR: null-ptr-deref KASAN: null-ptr-deref en el rango [0x0000000000000068-0x000000000000006f] CPU: 5 PID: 961 Comm: modprobe No contaminado 6.0.0-11331-gd465bff130bf-dirty RIP: 0010:kthread_destroy_worker+0x25/0xb0 Seguimiento de llamadas: drm_vblank_init_release+0x124/0x220 [drm] ? drm_crtc_vblank_restore+0x8b0/0x8b0 [drm] __drmm_add_action_or_reset+0x41/0x50 [drm] drm_vblank_init+0x282/0x310 [drm] vkms_init+0x35f/0x1000 [vkms] ? 0xffffffffc4508000 ? lock_is_held_type+0xd7/0x130 ? __kmem_cache_alloc_node+0x1c2/0x2b0 ? lock_is_held_type+0xd7/0x130 ? 0xffffffffc4508000 do_one_initcall+0xd0/0x4f0 ... do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0
Vulnerabilidad en kernel de Linux (CVE-2022-49828)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hugetlbfs: no elimine la página de error de la caché de páginas Este cambio es muy similar al cambio que se realizó para shmem [1] y resuelve el mismo problema, pero para HugeTLBFS. Actualmente, cuando se encuentra veneno en una página HugeTLB, la página se elimina de la caché de páginas. Eso significa que intentar mapear o leer esa página enorme en el futuro dará como resultado que se asigne una nueva página enorme en lugar de notificar al usuario que la página fue envenenada. Como indica [1], esto es efectivamente corrupción de memoria. La solución es dejar la página en la caché de páginas. Si el usuario intenta usar una página HugeTLB envenenada con una llamada al sistema, la llamada al sistema fallará con EIO, el mismo código de error que usa shmem. Para los intentos de mapear la página, el hilo obtendrá un SIGBUS BUS_MCEERR_AR. [1]: commit a76054266661 ("mm: shmem: no truncar la página si se produce un fallo de memoria")
Vulnerabilidad en kernel de Linux (CVE-2022-49829)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/scheduler: corrección del conteo de referencias de vallas. Se filtraron vallas de dependencias al finalizar procesos. Además, se obtuvo una referencia a la última valla programada.
Vulnerabilidad en kernel de Linux (CVE-2022-49830)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/drv: Se solucionó una posible fuga de memoria en drm_dev_init(). drm_dev_init() añadirá drm_dev_init_release() como devolución de llamada. Si drmm_add_action() falla, la función de liberación no se añadirá. Como resultado, el valor de referencia añadido por device_get() en drm_dev_init() no se incluirá en drm_dev_init_release(), lo que provoca la fuga de memoria. Utilice drmm_add_action_or_reset() en lugar de drmm_add_action() para evitar la fuga de memoria. objeto sin referencia 0xffff88810bc0c800 (tamaño 2048): comm "modprobe", pid 8322, jiffies 4305809845 (antigüedad 15.292s) volcado hexadecimal (primeros 32 bytes): e8 cc c0 0b 81 88 ff ff ff ff ff ff ff 00 00 00 00 ................ 20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $<............. backtrace: [<000000007251f72d>] __kmalloc+0x4b/0x1c0 [<0000000045f21f26>] platform_device_alloc+0x2d/0xe0 [<000000004452a479>] platform_device_register_full+0x24/0x1c0 [<0000000089f4ea61>] 0xffffffffa0736051 [<00000000235b2441>] do_one_initcall+0x7a/0x380 [<0000000001a4a177>] do_init_module+0x5c/0x230 [<000000002bf8a8e2>] load_module+0x227d/0x2420 [<00000000637d6d0a>] __do_sys_finit_module+0xd5/0x140 [<00000000c99fc324>] do_syscall_64+0x3f/0x90 [<000000004d85aa77>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Vulnerabilidad en kernel de Linux (CVE-2022-49831)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: inicializar la información de zona del dispositivo para la propagación. Al propagar en un sistema de archivos con zonas, es necesario inicializar la estructura btrfs_zoned_device_info de cada dispositivo; de lo contrario, al montar el sistema de archivos se producirá una desreferencia de puntero nulo. Esto fue descubierto por el caso de prueba btrfs/163 de fstests.
Vulnerabilidad en kernel de Linux (CVE-2022-49832)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: devicetree: corrección de la desreferencia de puntero nulo en pinctrl_dt_to_map Aquí está el informe de ERROR de KASAN sobre la desreferencia de puntero nulo: ERROR: KASAN: null-ptr-deref en strcmp+0x2e/0x50 Lectura de tamaño 1 en la dirección 0000000000000000 por la tarea python3/2640 Rastreo de llamadas: strcmp __of_find_property of_find_property pinctrl_dt_to_map kasprintf() devolvería un puntero NULL cuando kmalloc() no pudiera asignar. Por lo tanto, devuelve directamente ENOMEM, si kasprintf() devuelve un puntero NULL.
Vulnerabilidad en kernel de Linux (CVE-2022-49833)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: clonar información de dispositivo zonificado al clonar un dispositivo. Al clonar un btrfs_device, no se clona la estructura btrfs_zoned_device_info asociada al dispositivo en el caso de un sistema de archivos zonificado. Posteriormente, esto provoca una desreferencia de puntero nulo al acceder a zone_info del dispositivo, por ejemplo, al activar una zona. Esto fue descubierto por el caso de prueba btrfs/161 de fstests.
Vulnerabilidad en kernel de Linux (CVE-2022-49834)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige el error de use-after-free de ns_writer al volver a montar Si un sistema de archivos nilfs2 se degrada a solo lectura debido a la corrupción de metadatos en el disco y se vuelve a montar en modo de lectura/escritura, o si se realiza un remontaje de solo lectura de emergencia, se puede desconectar un escritor de registros y sincronizar el sistema de archivos al mismo tiempo. En estos casos, el use-after-free del escritor de registros (en adelante nilfs->ns_writer) puede ocurrir como se muestra en el siguiente escenario: Tarea1 Tarea2 -------------------------------- ---------------------------------- nilfs_construct_segment nilfs_segctor_sync init_wait init_waitqueue_entry add_wait_queue schedule nilfs_remount (caso de remontaje de R/W) nilfs_attach_log_writer nilfs_detach_log_writer nilfs_segctor_destroy kfree finish_wait _raw_spin_lock_irqsave __raw_spin_lock_irqsave do_raw_spin_lock debug_spin_lock_before <-- use-after-free Mientras la Tarea1 está en reposo, nilfs->ns_writer es liberado por la Tarea2. Después de que la Tarea1 se despierta, la Tarea1 accede a nilfs->ns_writer que ya está liberado. Este diagrama de escenario se basa en la publicación de Shigeru Yoshida [1]. Este parche corrige el problema al no desvincular nilfs->ns_writer al volver a montar, lo que evita que se produzca esta ejecución UAF. Además de este cambio, este parche también inserta algunas comprobaciones de solo lectura necesarias con la instancia de superbloque, donde solo se usaba el puntero ns_writer para comprobar si el sistema de archivos era de solo lectura.
Vulnerabilidad en kernel de Linux (CVE-2022-49835)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda: se corrige una posible fuga de memoria en 'add_widget_node'. 'kobject_add' podría asignar memoria a 'kobject->name' cuando devuelve un error. En esta función, si la llamada a 'kobject_add' falla, no se libera kobject. Por lo tanto, se llama a 'kobject_put' para reciclar recursos.
Vulnerabilidad en kernel de Linux (CVE-2022-49836)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: siox: Se corrige una posible fuga de memoria en siox_device_add(). Si device_register() devuelve un error en siox_device_add(), se debe liberar el nombre asignado por dev_set_name(). Como se indica en el comentario de device_register(), se debe usar put_device() para liberar la referencia en la ruta de error. Para solucionar esto, se debe llamar a put_device(); de esta manera, se puede liberar el nombre en kobject_cleanup() y sdevice se libera en siox_device_release(); configúrelo como nulo en la ruta de error.
Vulnerabilidad en kernel de Linux (CVE-2022-49838)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: borrar out_curr si se eliminan todos los fragmentos del mensaje actual. Zhen Chen informó de un fallo: corrupción de list_del, ffffa035ddf01c18->next es NULL ADVERTENCIA: CPU: 1 PID: 250682 en lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0 RIP: 0010:__list_del_entry_valid+0x59/0xe0 Rastreo de llamadas: sctp_sched_dequeue_common+0x17/0x70 [sctp] sctp_sched_fcfs_dequeue+0x37/0x50 [sctp] sctp_outq_flush_data+0x85/0x360 [sctp] sctp_outq_uncork+0x77/0xa0 [sctp] sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp] sctp_side_effects+0x37/0xe0 [sctp] sctp_do_sm+0xd0/0x230 [sctp] sctp_primitive_SEND+0x2f/0x40 [sctp] sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp] sctp_sendmsg+0x3d5/0x440 [sctp] sock_sendmsg+0x5b/0x70 y en sctp_sched_fcfs_dequeue() quitó de la cola un fragmento del flujo out_curr outq mientras este outq estaba vacío. Normalmente, stream->out_curr debe establecerse en NULL una vez que se hayan desencolado todos los fragmentos del mensaje actual, como se puede ver en sctp_sched_dequeue_done(). Sin embargo, en sctp_prsctp_prune_unsent(), dado que no es una desencola adecuada, no se llama a sctp_sched_dequeue_done() para realizar esto. Este parche soluciona este problema simplemente estableciendo out_curr en NULL cuando se desencola el último fragmento del mensaje actual del flujo out_curr en sctp_prsctp_prune_unsent().
Vulnerabilidad en kernel de Linux (CVE-2022-49841)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: imx: Agregar el gancho .thaw_noirq faltante. La siguiente advertencia se ve con una instancia UART que no es de consola cuando el sistema hiberna. [ 37.371969] ------------[ cortar aquí ]------------ [ 37.376599] uart3_root_clk ya está deshabilitado [ 37.380810] ADVERTENCIA: CPU: 0 PID: 296 en drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0 ... [ 37.506986] Rastreo de llamadas: [ 37.509432] clk_core_disable+0xa4/0xb0 [ 37.513270] clk_disable+0x34/0x50 [ 37.516672] imx_uart_thaw+0x38/0x5c [ 37.520250] platform_pm_thaw+0x30/0x6c [ 37.524089] dpm_run_callback.constprop.0+0x3c/0xd4 [ 37.528972] device_resume+0x7c/0x160 [ 37.532633] dpm_resume+0xe8/0x230 [ 37.536036] hibernation_snapshot+0x288/0x430 [ 37.540397] hibernate+0x10c/0x2e0 [ 37.543798] state_store+0xc4/0xd0 [ 37.547203] kobj_attr_store+0x1c/0x30 [ 37.550953] sysfs_kf_write+0x48/0x60 [ 37.554619] kernfs_fop_write_iter+0x118/0x1ac [ 37.559063] new_sync_write+0xe8/0x184 [ 37.562812] vfs_write+0x230/0x290 [ 37.566214] ksys_write+0x68/0xf4 [ 37.569529] __arm64_sys_write+0x20/0x2c [ 37.573452] invoke_syscall.constprop.0+0x50/0xf0 [ 37.578156] do_el0_svc+0x11c/0x150 [ 37.581648] el0_svc+0x30/0x140 [ 37.584792] el0t_64_sync_handler+0xe8/0xf0 [ 37.588976] el0t_64_sync+0x1a0/0x1a4 [ 37.592639] ---[ end trace 56e22eec54676d75 ] Al hibernar, el núcleo pm llama a los ganchos relacionados en secuencia como: .freeze .freeze_noirq .thaw_noirq .thaw Si el gancho .thaw_noirq está ausente, el reloj se deshabilitará en una llamada desequilibrada que genera la advertencia anterior. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_thaw clk_disable_unprepare() Agregar el gancho .thaw_noirq faltante como imx_uart_resume_noirq() corregirá la secuencia de llamada como se muestra a continuación y, por lo tanto, solucionará la advertencia. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_resume_noirq() clk_enable() imx_uart_thaw clk_disable_unprepare()
Vulnerabilidad en kernel de Linux (CVE-2022-49847)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: ti: am65-cpsw: Se corrige el error de segmentación en la descarga del módulo. Mueve la llamada am65_cpsw_nuss_phylink_cleanup() después de am65_cpsw_nuss_cleanup_ndev() para que phylink siga siendo válido para evitar el siguiente error de segmentación en la eliminación del módulo cuando el primer enlace esclavo está activo. [ 31.652944] No se puede manejar la solicitud de paginación del núcleo en la dirección virtual 00040008000005f4 [ 31.684627] Información de aborto de memoria: [ 31.687446] ESR = 0x0000000096000004 [ 31.704614] EC = 0x25: DABT (EL actual), IL = 32 bits [ 31.720663] SET = 0, FnV = 0 [ 31.723729] EA = 0, S1PTW = 0 [ 31.740617] FSC = 0x04: error de traducción de nivel 0 [ 31.756624] Información de aborto de datos: [ 31.759508] ISV = 0, ISS = 0x00000004 [ 31.776705] CM = 0, WnR = 0 [ 31.779695] [00040008000005f4] dirección entre los rangos de direcciones del usuario y del núcleo [ 31.808644] Error interno: Oops: 0000000096000004 [#1] PREEMPT SMP [ 31.814928] Modules linked in: wlcore_sdio wl18xx wlcore mac80211 libarc4 cfg80211 rfkill crct10dif_ce phy_gmii_sel ti_am65_cpsw_nuss(-) sch_fq_codel ipv6 [ 31.828776] CPU: 0 PID: 1026 Comm: modprobe Not tainted 6.1.0-rc2-00012-gfabfcf7dafdb-dirty #160 [ 31.837547] Hardware name: Texas Instruments AM625 (DT) [ 31.842760] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.849709] pc : phy_stop+0x18/0xf8 [ 31.853202] lr : phylink_stop+0x38/0xf8 [ 31.857031] sp : ffff80000a0839f0 [ 31.860335] x29: ffff80000a0839f0 x28: ffff000000de1c80 x27: 0000000000000000 [ 31.867462] x26: 0000000000000000 x25: 0000000000000000 x24: ffff80000a083b98 [ 31.874589] x23: 0000000000000800 x22: 0000000000000001 x21: ffff000001bfba90 [ 31.881715] x20: ffff0000015ee000 x19: 0004000800000200 x18: 0000000000000000 [ 31.888842] x17: ffff800076c45000 x16: ffff800008004000 x15: 000058e39660b106 [ 31.895969] x14: 0000000000000144 x13: 0000000000000144 x12: 0000000000000000 [ 31.903095] x11: 000000000000275f x10: 00000000000009e0 x9 : ffff80000a0837d0 [ 31.910222] x8 : ffff000000de26c0 x7 : ffff00007fbd6540 x6 : ffff00007fbd64c0 [ 31.917349] x5 : ffff00007fbd0b10 x4 : ffff00007fbd0b10 x3 : ffff00007fbd3920 [ 31.924476] x2 : d0a07fcff8b8d500 x1 : 0000000000000000 x0 : 0004000800000200 [ 31.931603] Call trace: [ 31.934042] phy_stop+0x18/0xf8 [ 31.937177] phylink_stop+0x38/0xf8 [ 31.940657] am65_cpsw_nuss_ndo_slave_stop+0x28/0x1e0 [ti_am65_cpsw_nuss] [ 31.947452] __dev_close_many+0xa4/0x140 [ 31.951371] dev_close_many+0x84/0x128 [ 31.955115] unregister_netdevice_many+0x130/0x6d0 [ 31.959897] unregister_netdevice_queue+0x94/0xd8 [ 31.964591] unregister_netdev+0x24/0x38 [ 31.968504] am65_cpsw_nuss_cleanup_ndev.isra.0+0x48/0x70 [ti_am65_cpsw_nuss] [ 31.975637] am65_cpsw_nuss_remove+0x58/0xf8 [ti_am65_cpsw_nuss]
Vulnerabilidad en kernel de Linux (CVE-2022-49849)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de coincidencia incorrecta en dev_args_match_device syzkaller encontró una aserción fallida: assertion failed: (args->devid != (u64)-1) || args->missing, en fs/btrfs/volumes.c:6921 Esto puede activarse cuando configuramos devid en (u64)-1 mediante ioctl. En este caso, se omitirá la coincidencia de devid y la coincidencia de dispositivo puede tener éxito incorrectamente. El parche 562d7b1512f7 introdujo esta función que se utiliza para hacer coincidir dispositivos. Esta función contiene dos escenarios de coincidencia; podemos distinguirlos comprobando el valor de args->missing en lugar de comprobar si args->devid y args->uuid son los valores predeterminados.
Vulnerabilidad en kernel de Linux (CVE-2022-49851)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: corrección de la configuración de memoria reservada Actualmente, RISC-V configura la memoria reservada utilizando la copia "temprana" del árbol de dispositivos. Como resultado, al intentar obtener una región de memoria reservada usando of_reserved_mem_lookup(), el puntero a las regiones de memoria reservadas usa la dirección anterior a la memoria virtual, lo que causa un pánico del kernel al intentar usar el nombre del búfer: Unable to handle kernel paging request at virtual address 00000000401c31ac Oops [#1] Módulos vinculados: CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc1-00001-g0d9d6953d834 #1 Nombre del hardware: Microchip PolarFire-SoC Icicle Kit (DT) epc : string+0x4a/0xea ra : vsnprintf+0x1e4/0x336 epc : ffffffff80335ea0 ra : ffffffff80338936 sp : ffffffff81203be0 gp: ffffffff812e0a98 tp: ffffffff8120de40 t0: 0000000000000000 t1: ffffffff81203e28 t2: 7265736572203a46 s0: ffffffff81203c20 s1: ffffffff81203e28 a0: ffffffff81203d22 a1: 0000000000000000 a2: ffffffff81203d08 a3: 0000000081203d21 a4: ffffffffffffffff a5: 00000000401c31ac a6 : ffff0a00ffffff04 a7 : ffffffffffffffff s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 : 0000000000000008 s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00 s8 : ffffffff80d9821a s9 : ffffffff81203d22 s10: 000000000000002 s11: ffffffff80d9821c t3 : ffffffff812f3617 t4: ffffffff812f3617 t5: ffffffff812f3618 t6: ffffffff81203d08 estado: 0000000200000100 dirección incorrecta: 00000000401c31ac causa: 000000000000000d [] vsnprintf+0x1e4/0x336 [] vprintk_store+0xf6/0x344 [] vprintk_emit+0x56/0x192 [] vprintk_default+0x16/0x1e [] vprintk+0x72/0x80 [] _printk+0x36/0x50 [] print_reserved_mem+0x1c/0x24 [] paging_init+0x528/0x5bc [] setup_arch+0xd0/0x592 [] start_kernel+0x82/0x73c early_init_fdt_scan_reserved_mem() no toma argumentos ya que opera en initial_boot_params, que se completa con early_init_dt_verify(). En RISC-V, early_init_dt_verify() se llama dos veces: una directamente, en setup_arch() si CONFIG_BUILTIN_DTB no está habilitado, y otra indirectamente, en una fase muy temprana del proceso de arranque, mediante parse_dtb() al llamar a early_init_dt_scan_nodes(). Esta primera llamada utiliza dtb_early_va para establecer initial_boot_params, que no se puede utilizar posteriormente en el proceso de arranque cuando se llama a early_init_fdt_scan_reserved_mem(). En arm64, por ejemplo, la llamada correspondiente a early_init_dt_scan_nodes() utiliza direcciones fixmap y no sufre el mismo problema. Desplace early_init_fdt_scan_reserved_mem() más adelante en la secuencia de arranque, después de la llamada directa a early_init_dt_verify() en setup_arch() para que los nombres utilicen las direcciones de memoria virtual correctas. Lo anterior supuso que CONFIG_BUILTIN_DTB no estaba configurado, pero debería funcionar igualmente en el caso en que lo esté: unflatted_and_copy_device_tree() también actualiza initial_boot_params.
Vulnerabilidad en kernel de Linux (CVE-2022-49858)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-pf: Se corrige la comprobación del umbral de SQE. La forma actual de comprobar el recuento de SQE disponibles, basada en el recuento de SQB actualizado por hardware, podría provocar que el controlador envíe un SQE incluso antes de que se procese en NAPI el CQE del SQE previamente transmitido en el mismo índice, lo que resulta en la pérdida de punteros SKB y, por lo tanto, una fuga. Se soluciona esto comprobando un índice de consumidor que se actualiza una vez procesado el CQE.
Vulnerabilidad en kernel de Linux (CVE-2022-49859)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: lapbether: se corrige el problema de un código de operación no válido en lapbeth_open(). Si lapb_register() falla al iniciar el dispositivo lapb por primera vez, NAPI no se desactiva. Por lo tanto, el problema de código de operación no válido se reporta al iniciar el dispositivo lapb por segunda vez. La información de la pila es la siguiente: [ 1958.311422][T11356] kernel BUG at net/core/dev.c:6442! [ 1958.312206][T11356] invalid opcode: 0000 [#1] PREEMPT SMP KASAN [ 1958.315979][T11356] RIP: 0010:napi_enable+0x16a/0x1f0 [ 1958.332310][T11356] Call Trace: [ 1958.332817][T11356] [ 1958.336135][T11356] lapbeth_open+0x18/0x90 [ 1958.337446][T11356] __dev_open+0x258/0x490 [ 1958.341672][T11356] __dev_change_flags+0x4d4/0x6a0 [ 1958.345325][T11356] dev_change_flags+0x93/0x160 [ 1958.346027][T11356] devinet_ioctl+0x1276/0x1bf0 [ 1958.346738][T11356] inet_ioctl+0x1c8/0x2d0 [ 1958.349638][T11356] sock_ioctl+0x5d1/0x750 [ 1958.356059][T11356] __x64_sys_ioctl+0x3ec/0x1790 [ 1958.365594][T11356] do_syscall_64+0x35/0x80 [ 1958.366239][T11356] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 1958.377381][T11356]
Vulnerabilidad en kernel de Linux (CVE-2022-49868)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: ralink: mt7621-pci: añadir centinela a la tabla de peculiaridades. Con la corrección de la variable mt7621 soc_dev_attr para registrar el SOC como dispositivo, el kernel experimentará un error en soc_device_match_attr. Esta prueba de peculiaridades se introdujo en el controlador de pruebas en el commit 9445ccb3714c ("staging: mt7621-pci-phy: añadir peculiaridades para la revisión 'E2' mediante 'soc_device_attribute'"). El controlador de pruebas se eliminó y se volvió a añadir posteriormente en el commit d87da32372a0 ("phy: ralink: Añadir controlador PHY para MT7621 PCIe PHY") para el kernel 5.11.
Vulnerabilidad en kernel de Linux (CVE-2022-49870)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: capacidades: corregir comportamiento indefinido en el cambio de bits para CAP_TO_MASK El cambio de un valor con signo de 32 bits por 31 bits no está definido, por lo que se cambia el bit significativo a sin signo. El seguimiento de llamadas de advertencia de UBSAN como se muestra a continuación: UBSAN: desplazamiento fuera de los límites en security/commoncap.c:1252:2 El desplazamiento a la izquierda de 1 por 31 lugares no se puede representar en el tipo 'int' Seguimiento de llamadas: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c cap_task_prctl+0x561/0x6f0 security_task_prctl+0x5a/0xb0 __x64_sys_prctl+0x61/0x8f0 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Vulnerabilidad en kernel de Linux (CVE-2022-49872)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: gso: corrección del pánico en frag_list con tipos de asignación de encabezado mixtos. Desde el commit 3dcbdb134f32 ("net: gso: corrección del error skb_segment al dividir gso_size de un skb alterado con frag_list de encabezado lineal"), se permite cambiar gso_size de un paquete GRO. Sin embargo, esta confirmación asume que basta con comprobar el primer miembro de list_skb; es decir, si alguno de los miembros de list_skb tiene un encabezado distinto de head_frag, el primero también lo tendrá. Resulta que esta suposición no se cumple. Hemos observado que se ha alcanzado BUG_ON en skb_segment cuando los skbs de frag_list tenían un head_frag distinto con el controlador vmxnet3. Esto se debe a que __netdev_alloc_skb y __napi_alloc_skb pueden devolver un skb con respaldo de página o asignado a km, según el tamaño solicitado. Como resultado, el último skb pequeño en el paquete GRO puede ser asignado a km. Hay tres ubicaciones diferentes donde esto puede ser corregido: (1) Podríamos revisar head_frag en GRO y no permitir que GROing skbs con diferente head_frag. Sin embargo, eso llevaría a una regresión del rendimiento en rutas de avance normales con gso_size sin modificar, donde !head_frag en el último paquete no es un problema. (2) Establecer un indicador en bpf_skb_net_grow y bpf_skb_net_shrink que indique que NETIF_F_SG no es deseable. Esto requeriría consumir un poco en sk_buff. Además, ese indicador puede ser desactivado cuando todos los skbs en la frag_list están en retroceso de página. Para mantener un buen rendimiento, bpf_skb_net_grow/shrink tendría que recorrer la frag_list. (3) Recorrer la frag_list en skb_segment al determinar si NETIF_F_SG debe ser borrado. Esto, por supuesto, ralentiza el proceso. Este parche implementa (3). Para limitar el impacto en el rendimiento de skb_segment, la lista solo se recorre para skb con SKB_GSO_DODGY configurado y gso_size modificado. Por lo tanto, las rutas normales no la alcanzarán. Podríamos revisar solo el último skb, pero como necesitamos recorrer la lista completa de todos modos, mejor optemos por lo seguro.
Vulnerabilidad en kernel de Linux (CVE-2022-49877)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: corrige la advertencia sk->sk_forward_alloc de sk_stream_kill_queues Al ejecutar las pruebas automáticas `test_sockmap`, aparece la siguiente advertencia: ADVERTENCIA: CPU: 2 PID: 197 en net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0 Seguimiento de llamadas: inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xd28/0x1380 ? tcp_v4_do_rcv+0x77/0x2c0 tcp_v4_do_rcv+0x77/0x2c0 __release_sock+0x106/0x130 __tcp_close+0x1a7/0x4e0 tcp_close+0x20/0x70 inet_release+0x3c/0x80 __sock_release+0x3a/0xb0 sock_close+0x14/0x20 __fput+0xa3/0x260 task_work_run+0x59/0xb0 exit_to_user_mode_prepare+0x1b3/0x1c0 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae El caso raíz está en el commit 84472b436e76 ("bpf, sockmap: Arreglar más archivos no cargados mientras msg tiene more_data"), donde utilicé msg->sg.size para reemplazar tosend, lo que causó fallas: if (msg->apply_bytes && msg->apply_bytes < tosend) tosend = psock->apply_bytes;
Vulnerabilidad en kernel de Linux (CVE-2022-49879)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de BUG_ON() cuando la entrada de directorio tiene un rec_len no válido El campo rec_len en la entrada de directorio debe ser un múltiplo de 4. Una imagen de sistema de archivos dañada se puede usar para generar un BUG() en ext4_rec_len_to_disk(), llamado desde make_indexed_dir(). ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/ext4/ext4.h:2413! ... RIP: 0010:make_indexed_dir+0x53f/0x5f0 ... Rastreo de llamadas: ? add_dirent_to_buf+0x1b2/0x200 ext4_add_entry+0x36e/0x480 ext4_add_nondir+0x2b/0xc0 ext4_create+0x163/0x200 path_openat+0x635/0xe90 do_filp_open+0xb4/0x160 ? __create_object.isra.0+0x1de/0x3b0 ? _raw_spin_unlock+0x12/0x30 do_sys_openat2+0x91/0x150 __x64_sys_open+0x6c/0xa0 do_syscall_64+0x3c/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 La solución simplemente agrega una llamada a ext4_check_dir_entry() para validar la entrada del directorio, devolviendo -EFSCORRUPTED si la entrada no es válida.
Vulnerabilidad en kernel de Linux (CVE-2022-49882)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: Rechazar intentos de consumir o actualizar gfn_to_pfn_cache inactivo. Rechazar kvm_gpc_check() y kvm_gpc_refresh() si la caché está inactiva. No verificar el indicador de activo durante la actualización es particularmente grave, ya que KVM puede terminar con una caché válida inactiva, lo que puede provocar diversos errores de use-after-free, como consumir un puntero de kernel nulo o perder una invalidación de mmu_notifier debido a que la caché no está en la lista de gfns para invalidar. Tenga en cuenta que "active" debe establecerse solo si la caché está en la lista de cachés, es decir, es accesible mediante eventos mmu_notifier. Si se produce un evento mmu_notifier relevante mientras la caché está activa, pero no está en la lista, KVM no adquirirá el bloqueo de la caché y, por lo tanto, no serializará el evento mmu_notifier con usuarios activos ni con kvm_gpc_refresh(). Una competencia entre KVM_XEN_ATTR_TYPE_SHARED_INFO y KVM_XEN_HVM_EVTCHN_SEND puede explotarse para activar el error. 1. Desactivar caché shinfo: kvm_xen_hvm_set_attr caso KVM_XEN_ATTR_TYPE_SHARED_INFO kvm_gpc_deactivate kvm_gpc_unmap gpc->valid = falso gpc->khva = NULL gpc->active = falso Resultado: activo = falso, válido = falso 2. Causar actualización de caché: kvm_arch_vm_ioctl caso KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast kvm_gpc_check devolver -EWOULDBLOCK porque !gpc->valid kvm_xen_set_evtchn_fast devolver -EWOULDBLOCK kvm_gpc_refresh hva_to_pfn_retry gpc->valid = verdadero gpc->khva = no NULL Resultado: activo = falso, válido = verdadero 3. Competencia ioctl KVM_XEN_HVM_EVTCHN_SEND contra ioctl KVM_XEN_ATTR_TYPE_SHARED_INFO: kvm_arch_vm_ioctl caso KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast read_lock gpc->lock kvm_xen_hvm_set_attr caso KVM_XEN_ATTR_TYPE_SHARED_INFO mutex_lock kvm->lock kvm_xen_shared_info_init kvm_gpc_activate gpc->khva = NULL kvm_gpc_check [ La comprobación pasa porque gpc->valid sigue siendo cierto, aunque gpc->khva ya sea NULL. ] shinfo = gpc->khva pending_bits = shinfo->evtchn_pending CRASH: test_and_set_bit(..., pending_bits)
Vulnerabilidad en kernel de Linux (CVE-2022-49883)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: smm: el número de GPR en la imagen SMRAM depende del formato de la imagen. En un host de 64 bits, si el invitado no tiene X86_FEATURE_LM, KVM accederá a 16 GPRS en la imagen SMRAM de 32 bits, lo que provocará un acceso a la RAM fuera de los límites. En un host de 32 bits, rsm_load_state_64/enter_smm_save_state_64 se compila, por lo que no se puede producir un desbordamiento de acceso.
Vulnerabilidad en kernel de Linux (CVE-2022-49884)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: Inicializar bloqueos de gfn_to_pfn_cache en un asistente dedicado. Trasladar la inicialización del bloqueo de gfn_to_pfn_cache a otro asistente y llamar al nuevo asistente durante la creación de la máquina virtual o la vCPU. Es posible que se produzcan condiciones de competencia debido a la capacidad de kvm_gfn_to_pfn_cache_init() de reinicializar los bloqueos de la caché. Por ejemplo: una competencia entre ioctl(KVM_XEN_HVM_EVTCHN_SEND) y kvm_gfn_to_pfn_cache_init() provoca un bloqueo de gpc de shinfo dañado. (hilo 1) | (hilo 2) | kvm_xen_set_evtchn_fast | read_lock_irqsave(&gpc->lock, ...) | | kvm_gfn_to_pfn_cache_init | rwlock_init(&gpc->lock) read_unlock_irqrestore(&gpc->lock, ...) | Renombra "cache_init" y "cache_destroy" como activate+deactivate para evitar que la caché se destruya o libere. Ten en cuenta que hay más ejecuciones en el nuevo nombre kvm_gpc_activate() que se abordarán por separado. [sean: se indica que se trata de una corrección de error]
Vulnerabilidad en kernel de Linux (CVE-2022-49886)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/tdx: Pánico en configuraciones incorrectas que generan #VE al acceder a memoria "privada". Toda la memoria normal del kernel es "memoria privada TDX". Esto incluye todo, desde las pilas del kernel hasta el texto del kernel. Gestionar excepciones en accesos arbitrarios a la memoria del kernel es prácticamente imposible, ya que pueden ocurrir en lugares muy peligrosos, como la entrada/salida del kernel. Sin embargo, el hardware TDX, en teoría, puede generar una excepción de virtualización (#VE) en cualquier acceso a memoria privada. Sin embargo, no es tan grave como parece. TDX se puede configurar para que nunca genere estas excepciones en memoria privada con un "atributo TD" llamado ATTR_SEPT_VE_DISABLE. El invitado no tiene forma de *configurar* este atributo, pero puede comprobarlo. Asegúrese de que ATTR_SEPT_VE_DISABLE esté configurado en el arranque inicial. Si no está configurado, utilice panic(). No hay una forma sensata de que Linux se ejecute con este atributo sin configurar, por lo que es apropiado usar panic(). Hay una pequeña ventana durante el arranque antes de la comprobación donde el kernel tiene un controlador de #VE temprano. Sin embargo, este controlador solo sirve para la E/S de puerto y también se pondrá en pánico() en cuanto detecte cualquier otro #VE, como uno generado por un acceso a memoria privada. [dhansen: Reescribir el registro de cambios y reorganizar con el nuevo tdx_parse_tdinfo(). Añadir la prueba de Kirill porque hice cambios desde que escribió esto.]
Vulnerabilidad en kernel de Linux (CVE-2022-49893)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxl/region: Se corrige la fuga de cxl_region y se limpian los objetivos al eliminar una región. Al eliminar una región, todos los objetivos previamente asignados a ella contienen referencias a ella. Para eliminar esas referencias, desvincula todos los objetivos durante la ejecución de unregister_region(). De lo contrario, el objeto de región se filtrará, ya que el espacio de usuario ha perdido la capacidad de desvincular objetivos una vez que se desmantela el sistema operativo de la región.
Vulnerabilidad en kernel de Linux (CVE-2022-49898)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige el mal manejo del registro de mod de árbol de nodos reasignados ¡Hemos estado viendo el siguiente ERROR de pánico en el kernel de producción en fs/btrfs/tree-mod-log.c:677! código de operación no válido: 0000 [#1] SMP RIP: 0010:tree_mod_log_rewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009f R09: 00000000000000000 R10: 0000000000000000 R11: 00000000000100c40 R12: 000000000000001 R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00 FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Rastreo de llamadas: btrfs_get_old_root+0x12b/0x420 btrfs_search_old_slot+0x64/0x2f0 ? tree_mod_log_oldest_root+0x3d/0xf0 resolve_indirect_ref+0xfd/0x660 ? ulist_alloc+0x31/0x60 ? kmem_cache_alloc_trace+0x114/0x2c0 find_parent_nodes+0x97a/0x17e0 ? ulist_alloc+0x30/0x60 btrfs_find_all_roots_safe+0x97/0x150 iterate_extent_inodes+0x154/0x370 ? btrfs_search_path_in_tree+0x240/0x240 iterate_inodes_from_logical+0x98/0xd0 ? btrfs_search_path_in_tree+0x240/0x240 btrfs_ioctl_logical_to_ino+0xd9/0x180 btrfs_ioctl+0xe2/0x2ec0 ? __mod_memcg_lruvec_state+0x3d/0x280 ? do_sys_openat2+0x6d/0x140 ? kretprobe_dispatcher+0x47/0x70 ? kretprobe_rethook_handler+0x38/0x50 ? rethook_trampoline_handler+0x82/0x140 ? arch_rethook_trampoline_callback+0x3b/0x50 ? kmem_cache_free+0xfb/0x270 ? do_sys_openat2+0xd5/0x140 __x64_sys_ioctl+0x71/0xb0 do_syscall_64+0x2d/0x40 Which is this code in tree_mod_log_rewind() switch (tm->op) { case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING: BUG_ON(tm->slot < n); Esto ocurre porque reproducimos los nodos en el orden en que sucedieron, y cuando hacemos un REPLACE registraremos un REMOVE_WHILE_FREEING para cada ranura, comenzando en 0. 'n' aquí es el número de elementos en este bloque, que en este caso era 1, pero teníamos 2 operaciones REMOVE_WHILE_FREEING. La causa raíz real de esto fue que estábamos reproduciendo operaciones para un bloque que no debería haberse reproducido. Considere la siguiente secuencia de eventos: 1. Tenemos una raíz ya modificada y ejecutamos btrfs_get_tree_mod_seq(). 2. Comenzamos a eliminar elementos de esta raíz, activando KEY_REPLACE para sus ranuras secundarias. 3. Eliminamos uno de los dos hijos a los que apunta este nodo raíz, lo que activa la promoción del hijo restante y libera este nodo. 4. Modificamos una nueva raíz y reasignamos el nodo anterior al nodo raíz de esta otra raíz. El registro de mod del árbol se parece a esto lógico 0 op KEY_REPLACE (ranura 1) seq 2 lógico 0 op KEY_REMOVE (ranura 1) seq 3 lógico 0 op KEY_REMOVE_WHILE_FREEING (ranura 0) seq 4 lógico 4096 op LOG_ROOT_REPLACE (antiguo lógico 0) seq 5 lógico 8192 op KEY_REMOVE_WHILE_FREEING (ranura 1) seq 6 lógico 8192 op KEY_REMOVE_WHILE_FREEING (ranura 0) seq 7 lógico 0 op LOG_ROOT_REPLACE (antiguo lógico 8192) seq 8 >A partir de aquí el error se activa con los siguientes pasos 1. Llama a btrfs_get_old_root() en new_root. 2. Llamamos a tree_mod_log_oldest_root(btrfs_root_node(new_root)), que actualmente tiene un valor lógico 0. 3. tree_mod_log_oldest_root() llama a tree_mod_log_search_oldest(), que nos proporciona la secuencia KEY_REPLACE 2. Dado que no es un LOG_ROOT_REPLACE, creemos erróneamente que no tenemos una raíz antigua, ya que esperamos que el cambio más reciente sea un LOG_ROOT_REPLACE. 4. En tree_mod_log_oldest_root(), no tenemos un LOG_ROOT_REPLACE, por lo que no establecemos old_root; simplemente usamos nuestra e ---truncated---
Vulnerabilidad en kernel de Linux (CVE-2022-49900)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: piix4: Adaptador de corrección que no se eliminará en piix4_remove() En piix4_probe(), el adaptador piix4 se registrará en: piix4_probe() piix4_add_adapters_sb800() / piix4_add_adapter() i2c_add_adapter() En función del tipo de dispositivo sondeado, se llamará a piix4_add_adapters_sb800() o a un solo piix4_add_adapter(). Para el primer caso, piix4_adapter_count se establece como el número de adaptadores, mientras que para otro caso no se establece y se mantiene predeterminado *cero*. Cuando se elimina piix4, piix4_remove() elimina los adaptadores agregados en piix4_probe(), basándose en el valor de piix4_adapter_count. Dado que el conteo es cero en el caso de un solo adaptador, este no se eliminará y se filtrarán las fuentes asignadas, como el cliente y el dispositivo i2c. Estas fuentes aún pueden ser accedidas por i2c o el bus, lo que puede causar problemas. Un caso que se reproduce fácilmente es que si se registra un nuevo adaptador, i2c obtendrá el adaptador filtrado e intentará llamar a smbus_algorithm, que ya se había liberado: Activado por: rmmod i2c_piix4 y modprobe max31730 ERROR: no se puede controlar el error de página para la dirección: ffffffffc053d860 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 3752 Comm: modprobe Tainted: G Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:i2c_default_probe (drivers/i2c/i2c-core-base.c:2259) i2c_core RSP: 0018:ffff888107477710 EFLAGS: 00000246 ... i2c_detect (controladores/i2c/i2c-core-base.c:2302) i2c_core __process_new_driver (controladores/i2c/i2c-core-base.c:1336) i2c_core bus_for_each_dev (controladores/base/bus.c:301) i2c_for_each_dev (controladores/i2c/i2c-core-base.c:1823) i2c_core i2c_register_driver (controladores/i2c/i2c-core-base.c:1861) i2c_core do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... ---[ fin del seguimiento 0000000000000000 ]--- Solucione este problema configurando correctamente piix4_adapter_count como 1 para el adaptador único de modo que se pueda quitar normalmente.
Vulnerabilidad en kernel de Linux (CVE-2023-53099)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: xilinx: no realice una asignación de memoria inactiva desde un contexto atómico El siguiente problema se descubrió utilizando lockdep: [ 6.691371] ERROR: función inactiva llamada desde un contexto no válido en include/linux/sched/mm.h:209 [ 6.694602] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0 [ 6.702431] 2 bloqueos mantenidos por swapper/0/1: [ 6.706300] #0: ffffff8800f6f188 (&dev->mutex){....}-{3:3}, en: __device_driver_lock+0x4c/0x90 [ 6.714900] #1: ffffffc009a2abb8 (enable_lock){....}-{2:2}, en: clk_enable_lock+0x4c/0x140 [ 6.723156] marca de evento irq: 304030 [ 6.726596] hardirqs se habilitaron por última vez en (304029): [] _raw_spin_unlock_irqrestore+0xc0/0xd0 [ 6.736142] hardirqs se deshabilitaron por última vez en (304030): [] clk_enable_lock+0xfc/0x140 [ 6.744742] softirqs se habilitaron por última vez en (303958): [] _stext+0x4f0/0x894 [ 6.752655] Última desactivación de softirqs en (303951): [] irq_exit+0x238/0x280 [ 6.760744] CPU: 1 PID: 1 Comm: swapper/0 Contaminado: GU 5.15.36 #2 [ 6.768048] Nombre del hardware: xlnx,zynqmp (DT) [ 6.772179] Rastreo de llamadas: [ 6.774584] dump_backtrace+0x0/0x300 [ 6.778197] show_stack+0x18/0x30 [ 6.781465] dump_stack_lvl+0xb8/0xec [ 6.785077] dump_stack+0x1c/0x38 [ 6.788345] ___might_sleep+0x1a8/0x2a0 [ 6.792129] __might_sleep+0x6c/0xd0 [ 6.795655] kmem_cache_alloc_trace+0x270/0x3d0 [ 6.800127] do_feature_check_call+0x100/0x220 [ 6.804513] zynqmp_pm_invoke_fn+0x8c/0xb0 [ 6.808555] zynqmp_pm_clock_getstate+0x90/0xe0 [ 6.813027] zynqmp_pll_is_enabled+0x8c/0x120 [ 6.817327] zynqmp_pll_enable+0x38/0xc0 [ 6.821197] clk_core_enable+0x144/0x400 [ 6.825067] clk_core_enable+0xd4/0x400 [ 6.828851] clk_core_enable+0xd4/0x400 [ 6.832635] clk_core_enable+0xd4/0x400 [ 6.836419] clk_core_enable+0xd4/0x400 [ 6.840203] clk_core_enable+0xd4/0x400 [ 6.843987] clk_core_enable+0xd4/0x400 [ 6.847771] clk_core_enable+0xd4/0x400 [ 6.851555] clk_core_enable_lock+0x24/0x50 [ 6.855683] clk_enable+0x24/0x40 [ 6.858952] fclk_probe+0x84/0xf0 [ 6.862220] platform_probe+0x8c/0x110 [ 6.865918] really_probe+0x110/0x5f0 [ 6.869530] __driver_probe_device+0xcc/0x210 [ 6.873830] driver_probe_device+0x64/0x140 [ 6.877958] __driver_attach+0x114/0x1f0 [ 6.881828] bus_for_each_dev+0xe8/0x160 [ 6.885698] driver_attach+0x34/0x50 [ 6.889224] bus_add_driver+0x228/0x300 [ 6.893008] driver_register+0xc0/0x1e0 [ 6.896792] __platform_driver_register+0x44/0x60 [ 6.901436] fclk_driver_init+0x1c/0x28 [ 6.905220] do_one_initcall+0x104/0x590 [ 6.909091] kernel_init_freeable+0x254/0x2bc [ 6.913390] kernel_init+0x24/0x130 [ 6.916831] ret_from_fork+0x10/0x20 Arréglelo pasando el indicador gfp GFP_ATOMIC para la asignación de memoria correspondiente.
Vulnerabilidad en kernel de Linux (CVE-2023-53100)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de ADVERTENCIA en ext4_update_inline_data. Syzbot encontró el siguiente problema: EXT4-fs (loop0): sistema de archivos montado 00000000-0000-0000-0000-00000000000 sin registro. Modo de cuota: ninguno. fscrypt: AES-256-CTS-CBC con implementación "cts-cbc-aes-aesni" fscrypt: AES-256-XTS con implementación "xts-aes-aesni" ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 0 PID: 5071 en mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525 Módulos vinculados: CPU: 1 PID: 5071 Comm: syz-executor263 No contaminado 6.2.0-rc1-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 26/10/2022 RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525 RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246 RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000 RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248 RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220 R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40 R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c FS: 0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 000000000003506f0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 00000000 __alloc_pages_node include/linux/gfp.h:237 [inline] alloc_pages_node include/linux/gfp.h:260 [inline] __kmalloc_large_node+0x95/0x1e0 mm/slab_common.c:1113 __do_kmalloc_node mm/slab_common.c:956 [inline] __kmalloc+0xfe/0x190 mm/slab_common.c:981 kmalloc include/linux/slab.h:584 [inline] kzalloc include/linux/slab.h:720 [inline] ext4_update_inline_data+0x236/0x6b0 fs/ext4/inline.c:346 ext4_update_inline_dir fs/ext4/inline.c:1115 [inline] ext4_try_add_inline_entry+0x328/0x990 fs/ext4/inline.c:1307 ext4_add_entry+0x5a4/0xeb0 fs/ext4/namei.c:2385 ext4_add_nondir+0x96/0x260 fs/ext4/namei.c:2772 ext4_create+0x36c/0x560 fs/ext4/namei.c:2817 lookup_open fs/namei.c:3413 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x12ac/0x2dd0 fs/namei.c:3711 do_filp_open+0x264/0x4f0 fs/namei.c:3741 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_openat fs/open.c:1342 [inline] __se_sys_openat fs/open.c:1337 [inline] __x64_sys_openat+0x243/0x290 fs/open.c:1337 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Above issue happens as follows: ext4_iget ext4_find_inline_data_nolock ->i_inline_off=164 i_inline_size=60 ext4_try_add_inline_entry __ext4_mark_inode_dirty ext4_expand_extra_isize_ea ->i_extra_isize=32 s_want_extra_isize=44 ext4_xattr_shift_entries ->after shift i_inline_off is incorrect, actually is change to 176 ext4_try_add_inline_entry ext4_update_inline_dir get_max_inline_xattr_value_size if (EXT4_I(inode)->i_inline_off) entry = (struct ext4_xattr_entry *)((void *)raw_inode + EXT4_I(inode)->i_inline_off); free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size)); ->Como la entrada es incorrecta, entonces 'libre' puede ser negativo ext4_update_inline_data valor = kzalloc(len, GFP_NOFS); -> len es un entero sin signo, posiblemente muy grande, por lo que se activa una advertencia al ejecutar 'kzalloc()'. Para resolver el problema anterior, debemos actualizar 'i_inline_off' después de 'ext4_xattr_shift_entries()'. No es necesario activar el indicador EXT4_STATE_MAY_INLINE_DATA, ya que ext4_mark_inode_dirty() ya lo activa si es necesario. Activar EXT4_STATE_MAY_INLINE_DATA cuando es necesario puede activar un error BUG_ON en ext4_writepages().
Vulnerabilidad en kernel de Linux (CVE-2023-53101)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: i_disksize cero al inicializar el inodo del cargador de arranque. Si el inodo del cargador de arranque nunca se ha usado antes, el inodo EXT4_IOC_SWAP_BOOT lo inicializará, incluyendo el establecimiento de i_size a 0. Sin embargo, si el cargador de arranque "nunca usado antes" tiene un i_size distinto de cero, entonces i_disksize será distinto de cero, y la inconsistencia entre i_size e i_disksize puede activar una advertencia del kernel: ADVERTENCIA: CPU: 0 PID: 2580 en fs/ext4/file.c:319 CPU: 0 PID: 2580 Comm: bb No contaminado 6.3.0-rc1-00004-g703695902cfa RIP: 0010:ext4_file_write_iter+0xbc7/0xd10 Rastreo de llamadas: vfs_write+0x3b1/0x5c0 ksys_write+0x77/0x160 __x64_sys_write+0x22/0x30 do_syscall_64+0x39/0x80 Reproductor: 1. crear una imagen dañada y montarla: mke2fs -t ext4 /tmp/foo.img 200 debugfs -wR "sif <5> size 25700" /tmp/foo.img mount -t ext4 /tmp/foo.img /mnt cd /mnt echo 123 > file 2. Ejecutar el programa reproductor: posix_memalign(&buf, 1024, 1024) fd = open("file", O_RDWR | Solucione esto configurando i_disksize e i_size en cero al iniciar el inodo del cargador de arranque.
Vulnerabilidad en kernel de Linux (CVE-2023-53102)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: xsk: deshabilitar la IRQ de txq antes de vaciar el hardware. ice_qp_dis() intenta detener un par de colas determinado que es objetivo de la conexión/desconexión del grupo xsk. Uno de los pasos consiste en deshabilitar las interrupciones en estas colas. Actualmente, el problema es que la IRQ de txq se desactiva *después* de vaciar el hardware, lo que no tiene efecto. ice_qp_dis(): -> ice_qvec_dis_irq() --> deshabilitar irq rxq --> vaciar hw -> ice_vsi_stop_tx_ring() --> deshabilitar irq txq El splat que aparece a continuación se puede activar siguiendo los pasos: - iniciar xdpsock SIN cargar el programa xdp - ejecutar xdp_rxq_info con la acción XDP_TX en esta interfaz - iniciar tráfico - finalizar xdpsock [ 256.312485] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000018 [ 256.319560] #PF: acceso de lectura del supervisor en modo kernel [ 256.324775] #PF: error_code(0x0000) - página no presente [ 256.329994] PGD 0 P4D 0 [ 256.332574] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 256.337006] CPU: 3 PID: 32 Comm: ksoftirqd/3 Contaminado: G OE 6.2.0-rc5+ #51 [ 256.345218] Nombre del hardware: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [ 256.355807] RIP: 0010:ice_clean_rx_irq_zc+0x9c/0x7d0 [ice] [ 256.361423] Code: b7 8f 8a 00 00 00 66 39 ca 0f 84 f1 04 00 00 49 8b 47 40 4c 8b 24 d0 41 0f b7 45 04 66 25 ff 3f 66 89 04 24 0f 84 85 02 00 00 <49> 8b 44 24 18 0f b7 14 24 48 05 00 01 00 00 49 89 04 24 49 89 44 [ 256.380463] RSP: 0018:ffffc900088bfd20 EFLAGS: 00010206 [ 256.385765] RAX: 000000000000003c RBX: 0000000000000035 RCX: 000000000000067f [ 256.393012] RDX: 0000000000000775 RSI: 0000000000000000 RDI: ffff8881deb3ac80 [ 256.400256] RBP: 000000000000003c R08: ffff889847982710 R09: 0000000000010000 [ 256.407500] R10: ffffffff82c060c0 R11: 0000000000000004 R12: 0000000000000000 [ 256.414746] R13: ffff88811165eea0 R14: ffffc9000d255000 R15: ffff888119b37600 [ 256.421990] FS: 0000000000000000(0000) GS:ffff8897e0cc0000(0000) knlGS:0000000000000000 [ 256.430207] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 256.436036] CR2: 0000000000000018 CR3: 0000000005c0a006 CR4: 00000000007706e0 [ 256.443283] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 256.450527] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 256.457770] PKRU: 55555554 [ 256.460529] Call Trace: [ 256.463015] [ 256.465157] ? ice_xmit_zc+0x6e/0x150 [ice] [ 256.469437] ice_napi_poll+0x46d/0x680 [ice] [ 256.473815] ? _raw_spin_unlock_irqrestore+0x1b/0x40 [ 256.478863] __napi_poll+0x29/0x160 [ 256.482409] net_rx_action+0x136/0x260 [ 256.486222] __do_softirq+0xe8/0x2e5 [ 256.489853] ? smpboot_thread_fn+0x2c/0x270 [ 256.494108] run_ksoftirqd+0x2a/0x50 [ 256.497747] smpboot_thread_fn+0x1c1/0x270 [ 256.501907] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 256.506594] kthread+0xea/0x120 [ 256.509785] ? __pfx_kthread+0x10/0x10 [ 256.513597] ret_from_fork+0x29/0x50 [ 256.517238] De hecho, las IRQ no se deshabilitaron y napi logró programarse y ejecutarse mientras el puntero xsk_pool aún era válido, pero el anillo de SW de punteros xdp_buff ya estaba liberado. Para solucionar esto, llame a ice_qvec_dis_irq() después de ice_vsi_stop_tx_ring(). Además, elimine la llamada redundante a ice_clean_rx_ring(); esto se gestiona en ice_qp_clean_rings().
Vulnerabilidad en kernel de Linux (CVE-2023-53103)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: enlace: restaurar el indicador IFF_SLAVE del enlace si falla la ejecución de un dispositivo no ethernet. syzbot reportó una advertencia[1] donde el dispositivo de enlace es esclavo e intentamos ejecutar un dispositivo no ethernet como primer esclavo, lo cual falla. Sin embargo, en la ruta de error, cuando ether_setup() restaura el dispositivo de enlace, también borra todos los indicadores. En mi corrección anterior[2], restauré el indicador IFF_MASTER, pero no consideré la posibilidad de que el dispositivo de enlace también sea esclavo con IFF_SLAVE activado, por lo que también debemos restaurar ese indicador. Use el asistente bond_ether_setup, que realiza la acción correcta y restaura los indicadores del enlace correctamente. Pasos para reproducir usando un dev nlmon: $ ip l add nlmon0 type nlmon $ ip l add bond1 type bond $ ip l add bond2 type bond $ ip l set bond1 master bond2 $ ip l set dev nlmon0 master bond1 $ ip -dl sh dev bond1 22: bond1: mtu 1500 qdisc noqueue master bond2 state DOWN mode DEFAULT group default qlen 1000 (ahora el indicador IFF_SLAVE de bond1 desapareció y recibiremos una advertencia[3] si intentamos eliminarlo) [1] https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3ef [2] commit 7d5cd2ce5292 ("bonding: "Manejar correctamente el cambio de tipo de enlace en caso de fallo de esclavización") [3] Ejemplo de advertencia: [27.008664] bond1: (esclavo nlmon0): El dispositivo esclavo especificado no admite la configuración de la dirección MAC [27.008692] bond1: (esclavo nlmon0): Error -95 al llamar a set_mac_address [32.464639] bond1 (anulando registro): Se liberaron todos los esclavos [32.464685] ------------[cortar aquí]------------ [32.464686] ADVERTENCIA: CPU: 1 PID: 2004 en net/core/dev.c:10829 unregister_netdevice_many+0x72a/0x780 [32.464694] Módulos vinculados: br_netfilter puente enlace virtio_net [32.464699] CPU: 1 PID: 2004 Comm: ip Kdump: cargado No contaminado 5.18.0-rc3+ #47 [ 32.464703] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 01/04/2014 [ 32.464704] RIP: 0010:unregister_netdevice_many+0x72a/0x780 [ 32.464707] Código: 99 fd ff ff ba 90 1a 00 00 48 c7 c6 f4 02 66 96 48 c7 c7 20 4d 35 96 c6 05 fa c7 2b 02 01 e8 be 6f 4a 00 0f 0b e9 73 fd ff ff <0f> 0b e9 5f fd ff ff 80 3d e3 c7 2b 02 00 0f 85 3b fd ff ff ba 59 [ 32.464710] RSP: 0018:ffffa006422d7820 EFLAGS: 00010206 [ 32.464712] RAX: ffff8f6e077140a0 RBX: ffffa006422d7888 RCX: 0000000000000000 [ 32.464714] RDX: ffff8f6e12edbe58 RSI: 0000000000000296 RDI: ffffffff96d4a520 [32.464716] RBP: ffff8f6e07714000 R08: ffffffff96d63600 R09: ffffa006422d7728 [32.464717] R10: 000000000000ec0 R11: ffffffff9698c988 R12: ffff8f6e12edb140 [32.464719] R13: muerto000000000122 R14: muerto000000000100 R15: ffff8f6e12edb140 [32.464723] FS: 00007f297c2f1740(0000) GS:ffff8f6e5d900000(0000) knlGS:0000000000000000 [ 32.464725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 32.464726] CR2: 00007f297bf1c800 CR3: 00000000115e8000 CR4: 0000000000350ee0 [ 32.464730] Rastreo de llamadas: [ 32.464763] [ 32.464767] rtnl_dellink+0x13e/0x380 [ 32.464776] ? cred_has_capability.isra.0+0x68/0x100 [ 32.464780] ? __rtnl_unlock+0x33/0x60 [ 32.464783] ? bpf_lsm_capset+0x10/0x10 [ 32.464786] ? security_capable+0x36/0x50 [ 32.464790] rtnetlink_rcv_msg+0x14e/0x3b0 [ 32.464792] ? _copy_to_iter+0xb1/0x790 [ 32.464796] ? post_alloc_hook+0xa0/0x160 [ 32.464799] ? rtnl_calcit.isra.0+0x110/0x110 [ 32.464802] netlink_rcv_skb+0x50/0xf0 [ 32.464806] netlink_unicast+0x216/0x340 [ 32.464809] netlink_sendmsg+0x23f/0x480 [ 32.464812] sock_sendmsg+0x5e/0x60 [ 32.464815] ____sys_sendmsg+0x22c/0x270 [ 32.464818] ? import_iovec+0x17/0x20 [ 32.464821] ? sendmsg_copy_msghdr+0x59/0x90 [ 32.464823] ? do_set_pte+0xa0/0xe0 [ 32.464828] ___sys_sendmsg+0x81/0xc0 [ 32.464832] ? mod_objcg_state+0xc6/0x300 [ 32.464835] ? refill_obj_stock+0xa9/0x160 [ 32.464838] ? memcg_slab_free_hook+0x1a5/0x1f0 [ 32.464842] __sys_sendm ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2023-53105)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Se corrige la limpieza de null-ptr deref en el bloqueo de encap. Durante la descarga del módulo mientras un flujo tc de igual aún está descargado, primero se cambia el perfil de representante de enlace ascendente de igual a un perfil NIC, y así se destruye el bloqueo de encap vecino. A continuación, durante la descarga, se anula el registro de los representantes VF netdevs, lo que provoca la eliminación del flujo tc original no par, lo que elimina el flujo par. La eliminación del flujo par separa la entrada de encap e intenta tomar el bloqueo de encap ya destruido, causando el siguiente rastro. Solucione esto borrando los flujos de igual durante la limpieza del conmutador de eswitch de tc (mlx5e_tc_esw_cleanup()). Rastreo relevante: [ 4316.837128] ERROR: desreferencia de puntero NULL del núcleo, dirección: 00000000000001d8 [ 4316.842239] RIP: 0010:__mutex_lock+0xb5/0xc40 [ 4316.851897] Rastreo de llamada: [ 4316.852481] [ 4316.857214] mlx5e_rep_neigh_entry_release+0x93/0x790 [mlx5_core] [ 4316.858258] mlx5e_rep_encap_entry_detach+0xa7/0xf0 [mlx5_core] [ 4316.859134] mlx5e_encap_dealloc+0xa3/0xf0 [mlx5_core] [ 4316.859867] clean_encap_dests.part.0+0x5c/0xe0 [mlx5_core] [ 4316.860605] mlx5e_tc_del_fdb_flow+0x32a/0x810 [mlx5_core] [ 4316.862609] __mlx5e_tc_del_fdb_peer_flow+0x1a2/0x250 [mlx5_core] [ 4316.863394] mlx5e_tc_del_flow+0x(/0x630 [mlx5_core] [ 4316.864090] mlx5e_flow_put+0x5f/0x100 [mlx5_core] [ 4316.864771] mlx5e_delete_flower+0x4de/0xa40 [mlx5_core] [ 4316.865486] tc_setup_cb_reoffload+0x20/0x80 [ 4316.865905] fl_reoffload+0x47c/0x510 [cls_flower] [ 4316.869181] tcf_block_playback_offloads+0x91/0x1d0 [ 4316.869649] tcf_block_unbind+0xe7/0x1b0 [ 4316.870049] tcf_block_offload_cmd.isra.0+0x1ee/0x270 [ 4316.879266] tcf_block_offload_unbind+0x61/0xa0 [ 4316.879711] __tcf_block_put+0xa4/0x310
Vulnerabilidad en kernel de Linux (CVE-2023-53106)
Severidad: ALTA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: st-nci: Fix use after free bug en ndlc_remove debido a una condición de ejecución Este error afecta tanto a st_nci_i2c_remove como a st_nci_spi_remove. Tomemos st_nci_i2c_remove como ejemplo. En st_nci_i2c_probe, llamó a ndlc_probe y vinculó &ndlc->sm_work con llt_ndlc_sm_work. Cuando llama a ndlc_recv o al controlador de tiempo de espera, finalmente llamará a schedule_work para iniciar el trabajo. Cuando llamamos a st_nci_i2c_remove para eliminar el controlador, puede haber una secuencia como la siguiente: Arréglelo finalizando el trabajo antes de la limpieza en ndlc_remove CPU0 CPU1 |llt_ndlc_sm_work st_nci_i2c_remove | ndlc_remove | st_nci_remove | nci_free_device| kfree(ndev) | //liberar ndlc->ndev | |llt_ndlc_rcv_queue |nci_recv_frame |//usar ndlc->ndev
Vulnerabilidad en kernel de Linux (CVE-2023-53107)
Severidad: ALTA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: veth: Corrección del use after free en XDP_REDIRECT. el commit 718a18a0c8a6 ("veth: Reestructurar veth_xdp_rcv_skb para aceptar skb no lineal") introdujo un error que provocaba que se intentara usar pskb_expand_head() si el espacio libre era inferior a XDP_PACKET_HEADROOM. Sin embargo, esto utiliza kmalloc para expandir el espacio libre, lo que posteriormente permitirá que consuma_skb() libere el skb mientras AF_XDP lo siga utilizando. Anteriormente, si el espacio libre era inferior a XDP_PACKET_HEADROOM, se asignaba un nuevo skb desde las páginas, por lo que esto restaura ese comportamiento. ERROR: KASAN: use-after-free en __xsk_rcv+0x18d/0x2c0 Lectura de tamaño 78 en la dirección ffff888976250154 por la tarea napi/iconduit-g/148640 CPU: 5 PID: 148640 Comm: napi/iconduit-g Kdump: cargado Contaminado: GO 6.1.4-cloudflare-kasan-2023.1.2 #1 Nombre del hardware: Quanta Computer Inc. QuantaPlex T41S-2U/S2S-MB, BIOS S2S_3B10.03 21/06/2018 Seguimiento de llamadas: dump_stack_lvl+0x34/0x48 print_report+0x170/0x473 ? __xsk_rcv+0x18d/0x2c0 kasan_report+0xad/0x130 ? __xsk_rcv+0x18d/0x2c0 kasan_check_range+0x149/0x1a0 memcpy+0x20/0x60 __xsk_rcv+0x18d/0x2c0 __xsk_map_redirect+0x1f3/0x490 ? veth_xdp_rcv_skb+0x89c/0x1ba0 [veth] xdp_do_redirect+0x5ca/0xd60 veth_xdp_rcv_skb+0x935/0x1ba0 [veth] ? __netif_receive_skb_list_core+0x671/0x920 ? veth_xdp+0x670/0x670 [veth] veth_xdp_rcv+0x304/0xa20 [veth] ? do_xdp_generic+0x150/0x150 ? veth_xdp_rcv_one+0xde0/0xde0 [veth] ? _raw_spin_lock_bh+0xe0/0xe0 ? newidle_balance+0x887/0xe30 ? __perf_event_task_sched_in+0xdb/0x800 veth_poll+0x139/0x571 [veth] ? veth_xdp_rcv+0xa20/0xa20 [veth] ? _raw_spin_unlock+0x39/0x70 ? finish_task_switch.isra.0+0x17e/0x7d0 ? __switch_to+0x5cf/0x1070 ? __schedule+0x95b/0x2640 ? io_schedule_timeout+0x160/0x160 __napi_poll+0xa1/0x440 napi_threaded_poll+0x3d1/0x460 ? __napi_poll+0x440/0x440 ? __kthread_parkme+0xc6/0x1f0 ? __napi_poll+0x440/0x440 kthread+0x2a2/0x340 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 Freed by task 148640: kasan_save_stack+0x23/0x50 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40 ____kasan_slab_free+0x169/0x1d0 slab_free_freelist_hook+0xd2/0x190 __kmem_cache_free+0x1a1/0x2f0 skb_release_data+0x449/0x600 consume_skb+0x9f/0x1c0 veth_xdp_rcv_skb+0x89c/0x1ba0 [veth] veth_xdp_rcv+0x304/0xa20 [veth] veth_poll+0x139/0x571 [veth] __napi_poll+0xa1/0x440 napi_threaded_poll+0x3d1/0x460 kthread+0x2a2/0x340 ret_from_fork+0x22/0x30 The buggy address belongs to the object at ffff888976250000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 340 bytes inside of 2048-byte region [ffff888976250000, ffff888976250800) The buggy address belongs to the physical page: page:00000000ae18262a refcount:2 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x976250 head:00000000ae18262a order:3 compound_mapcount:0 compound_pincount:0 flags: 0x2ffff800010200(slab|head|node=0|zone=2|lastcpupid=0x1ffff) raw: 002ffff800010200 0000000000000000 dead000000000122 ffff88810004cf00 raw: 0000000000000000 0000000080080008 00000002ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888976250000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888976250080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff888976250100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888976250180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888976250200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Vulnerabilidad en kernel de Linux (CVE-2023-53108)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/iucv: Se corrige que el tamaño de los datos de interrupción iucv_irq_data deba ser 4 bytes mayor. Estos bytes no son utilizados por el módulo iucv, sino por el hipervisor z/VM en caso de desconfiguración de una CPU. Reportado como: BUG dma-kmalloc-64 (No contaminado): kmalloc Redzone sobrescrito ----------------------------------------------------------------------------- 0x0000000000400564-0x0000000000400567 @offset=1380. First byte 0x80 instead of 0xcc Allocated in iucv_cpu_prepare+0x44/0xd0 age=167839 cpu=2 pid=1 __kmem_cache_alloc_node+0x166/0x450 kmalloc_node_trace+0x3a/0x70 iucv_cpu_prepare+0x44/0xd0 cpuhp_invoke_callback+0x156/0x2f0 cpuhp_issue_call+0xf0/0x298 __cpuhp_setup_state_cpuslocked+0x136/0x338 __cpuhp_setup_state+0xf4/0x288 iucv_init+0xf4/0x280 do_one_initcall+0x78/0x390 do_initcalls+0x11a/0x140 kernel_init_freeable+0x25e/0x2a0 kernel_init+0x2e/0x170 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 Freed in iucv_init+0x92/0x280 age=167839 cpu=2 pid=1 __kmem_cache_free+0x308/0x358 iucv_init+0x92/0x280 do_one_initcall+0x78/0x390 do_initcalls+0x11a/0x140 kernel_init_freeable+0x25e/0x2a0 kernel_init+0x2e/0x170 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 Slab 0x0000037200010000 objects=32 used=30 fp=0x0000000000400640 flags=0x1ffff00000010200(slab|head|node=0|zone=0| Object 0x0000000000400540 @offset=1344 fp=0x0000000000000000 Redzone 0000000000400500: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400510: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400520: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400530: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Object 0000000000400540: 00 01 00 03 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object 0000000000400550: f3 86 81 f2 f4 82 f8 82 f0 f0 f0 f0 f0 f0 f0 f2 ................ Object 0000000000400560: 00 00 00 00 80 00 00 00 cc cc cc cc cc cc cc cc ................ Object 0000000000400570: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400580: cc cc cc cc cc cc cc cc ........ Padding 00000000004005d4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding 00000000004005e4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding 00000000004005f4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ CPU: 6 PID: 121030 Comm: 116-pai-crypto. Not tainted 6.3.0-20230221.rc0.git4.99b8246b2d71.300.fc37.s390x+debug #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Rastreo de llamadas: [<000000032aa034ec>] dump_stack_lvl+0xac/0x100 [<0000000329f5a6cc>] check_bytes_and_report+0x104/0x140 [<0000000329f5aa78>] check_object+0x370/0x3c0 [<0000000329f5ede6>] free_debug_processing+0x15e/0x348 [<0000000329f5f06a>] free_to_partial_list+0x9a/0x2f0 [<0000000329f5f4a4>] __slab_free+0x1e4/0x3a8 [<0000000329f61768>] __kmem_cache_free+0x308/0x358 [<000000032a91465c>] iucv_cpu_dead+0x6c/0x88 [<0000000329c2fc66>] cpuhp_invoke_callback+0x156/0x2f0 [<000000032aa062da>] _cpu_down.constprop.0+0x22a/0x5e0 [<0000000329c3243e>] cpu_device_down+0x4e/0x78 [<000000032a61dee0>] device_offline+0xc8/0x118 [<000000032a61e048>] online_store+0x60/0xe0 [<000000032a08b6b0>] kernfs_fop_write_iter+0x150/0x1e8 [<0000000329fab65c>] vfs_write+0x174/0x360 [<0000000329fab9fc>] ksys_write+0x74/0x100 [<000000032aa03a5a>] __do_syscall+0x1da/0x208 [<000000032aa177b2>] system_call+0x82/0xb0 INFORMACIÓN: LockDep está desactivado. CORRECCIÓN dma-kmalloc-64: Restaurando la zona roja de kmalloc 0x0000000000400564-0x0000000000400567=0xcc CORRECCIÓN dma-kmalloc-64: Objeto en 0x0000000000400540 no liberado.
Vulnerabilidad en kernel de Linux (CVE-2023-53109)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tunnels: annotate, los accesos sin bloqueo a los túneles IP dev->needed_headroom aparentemente pueden actualizar dev->needed_headroom en su ruta de transmisión. Este parche soluciona la transmisión de tres túneles y también los ayudantes principales LL_RESERVED_SPACE() y LL_RESERVED_SPACE_EXTRA(). Es posible que se requieran más cambios para completar la solución. ERROR: KCSAN: ejecución de datos en ip_tunnel_xmit / ip_tunnel_xmit leído a 0xffff88815b9da0ec de 2 bytes por la tarea 888 en la CPU 1: ip_tunnel_xmit+0x1270/0x1730 net/ipv4/ip_tunnel.c:803 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430 dst_output include/net/dst.h:444 [inline] ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126 iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430 dst_output include/net/dst.h:444 [inline] ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126 iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430 dst_output include/net/dst.h:444 [inline] ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126 iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/i ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2023-53110)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: corrección de sndbuf_desc NULL en smc_cdc_tx_handler(). Al realizar una prueba de estrés en SMC-R con el controlador rmmod mlx5_ib durante la prueba wrk/nginx, se observó la probabilidad de generar un pánico al terminar todos los grupos de enlaces. Este problema se debe a la competencia entre smc_smcr_terminate_all() y smc_buf_create(). smc_smcr_terminate_all smc_buf_create /* init */ conn->sndbuf_desc = NULL; ... __smc_lgr_terminate smc_conn_kill smc_close_abort smc_cdc_get_slot_and_msg_send __softirqentry_text_start smc_wr_tx_process_cqe smc_cdc_tx_handler READ(conn->sndbuf_desc->len); /* pánico debido a NULL sndbuf_desc */ conn->sndbuf_desc = xxx; Este parche intenta solucionar el problema verificando siempre sndbuf_desc antes de enviar cualquier mensaje de cdc, para asegurarse de que no se vea ningún puntero nulo durante el procesamiento de cqe.
Vulnerabilidad en kernel de Linux (CVE-2023-53111)
Severidad: ALTA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: loop: Se corrigen los problemas de use after free. do_req_filebacked() llama a blk_mq_complete_request() de forma síncrona o asíncrona al usar E/S asíncrona, a menos que falle la asignación de memoria. Por lo tanto, se debe modificar loop_handle_cmd() para que no desreferencia «cmd» ni «rq» tras la finalización de do_req_filebacked(), a menos que estemos seguros de que la solicitud aún no se ha completado. Este parche corrige el siguiente fallo del kernel: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000054 Seguimiento de llamadas: css_put.42938+0x1c/0x1ac loop_process_work+0xc8c/0xfd4 loop_rootcg_workfn+0x24/0x34 process_one_work+0x244/0x558worker_thread+0x400/0x8fckthread+0x16c/0x1e0ret_from_fork+0x10/0x20
Vulnerabilidad en kernel de Linux (CVE-2023-53112)
Severidad: ALTA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/sseu: fix max_subslices array-index-out-of-bounds access Parece que el commit bc3c5e0809ae ("drm/i915/sseu: No intente almacenar la máscara EU internamente en formato UAPI") expuso un posible acceso fuera de los límites, informado por UBSAN de la siguiente manera en una computadora portátil con una tarjeta i915 gen 11: UBSAN: array-index-out-of-bounds en drivers/gpu/drm/i915/gt/intel_sseu.c:65:27 el índice 6 está fuera de rango para el tipo 'u16 [6]' CPU: 2 PID: 165 Comm: systemd-udevd No contaminado 6.2.0-9-generic #9-Ubuntu Nombre del hardware: Dell Inc. XPS 13 9300/077Y9N, BIOS 1.11.0 22/03/2022 Seguimiento de llamadas: show_stack+0x4e/0x61 dump_stack_lvl+0x4a/0x6f dump_stack+0x10/0x18 ubsan_epilogue+0x9/0x3a __ubsan_handle_out_of_bounds.cold+0x42/0x47 gen11_compute_sseu_info+0x121/0x130 [i915] intel_sseu_info_init+0x15d/0x2b0 [i915] intel_gt_init_mmio+0x23/0x40 [i915] i915_driver_mmio_probe+0x129/0x400 [i915] ? intel_gt_probe_all+0x91/0x2e0 [i915] i915_driver_probe+0xe1/0x3f0 [i915] ? drm_privacy_screen_get+0x16d/0x190 [drm] ? acpi_dev_found+0x64/0x80 i915_pci_probe+0xac/0x1b0 [i915] ... Según la definición de sseu_dev_info, eu_mask->hsw está limitado a un máximo de GEN_MAX_SS_PER_HSW_SLICE (6) subsecciones, pero gen11_sseu_info_init() puede establecer potencialmente 8 subsecciones, en el caso de !IS_JSL_EHL(gt->i915). Para solucionar esto, reserve hasta 8 espacios para max_subslices en la estructura eu_mask. (Seleccionado de la confirmación 3cba09a6ac86ea1d456909626eb2685596c07822)
Vulnerabilidad en kernel de Linux (CVE-2023-53113)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: nl80211: se corrige la deref NULL-ptr en la comprobación offchan. Si, por ejemplo, en modo AP, el enlace ya fue creado por el espacio de usuario, pero aún no se activó, tiene una definición de canal (chandef), pero esta no es válida y no tiene canal. Verifique esto e ignore este enlace.
Vulnerabilidad en kernel de Linux (CVE-2023-53114)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: Se soluciona el fallo del kernel durante el reinicio cuando el adaptador está en modo de recuperación Si el controlador detecta durante el sondeo que el firmware está en modo de recuperación, se llama a i40e_init_recovery_mode() y se omite el resto de la función del sondeo, incluido pci_set_drvdata(). La llamada posterior a i40e_shutdown() durante el apagado/reinicio desreferencia el puntero NULL, ya que pci_get_drvdata() devuelve NULL. Para solucionarlo, llame también a pci_set_drvdata() durante el ingreso al modo de recuperación. Reproductor: 1) Tengamos la NIC i40e con el firmware en modo de recuperación 2) Ejecute el reinicio Resultado: [ 139.084698] i40e: Controlador de red Intel(R) Ethernet Connection XL710 [ 139.090959] i40e: Copyright (c) 2013 - 2019 Intel Corporation. [ 139.108438] i40e 0000:02:00.0: Se detectó el modo de recuperación de firmware. Funcionalidad limitada. [ 139.116439] i40e 0000:02:00.0: Consulte la Guía del usuario de adaptadores y dispositivos Intel(R) Ethernet para obtener más información sobre el modo de recuperación de firmware. [ 139.129499] i40e 0000:02:00.0: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a] [ 139.215932] i40e 0000:02:00.0 enp2s0f0: renombrado de eth0 [ 139.223292] i40e 0000:02:00.1: Se detectó modo de recuperación de firmware. Funcionalidad limitada. [ 139.231292] i40e 0000:02:00.1: Consulte la Guía del usuario de adaptadores y dispositivos Intel(R) Ethernet para obtener más información sobre el modo de recuperación de firmware. [ 139.244406] i40e 0000:02:00.1: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a] [ 139.329209] i40e 0000:02:00.1 enp2s0f1: renombrado de eth0 ... [ 156.311376] ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000006c2 [ 156.318330] #PF: acceso de escritura del supervisor en modo kernel [ 156.323546] #PF: error_code(0x0002) - no presente página [ 156.328679] PGD 0 P4D 0 [ 156.331210] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 156.335567] CPU: 26 PID: 15119 Comm: reboot Tainted: GE 6.2.0+ #1 [ 156.343126] Nombre del hardware: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022 [ 156.353369] RIP: 0010:i40e_shutdown+0x15/0x130 [i40e] [ 156.358430] Code: c1 fc ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 fd 53 48 8b 9f 48 01 00 00 80 8b c2 06 00 00 04 f0 80 8b c0 06 00 00 08 48 8d bb 08 08 00 [ 156.377168] RSP: 0018:ffffb223c8447d90 EFLAGS: 00010282 [ 156.382384] RAX: ffffffffc073ee70 RBX: 0000000000000000 RCX: 0000000000000001 [ 156.389510] RDX: 0000000080000001 RSI: 0000000000000246 RDI: ffff95db49988000 [ 156.396634] RBP: ffff95db49988000 R08: ffffffffffffffff R09: ffffffff8bd17d40 [ 156.403759] R10: 0000000000000001 R11: ffffffff8a5e3d28 R12: ffff95db49988000 [ 156.410882] R13: ffffffff89a6fe17 R14: ffff95db49988150 R15: 0000000000000000 [ 156.418007] FS: 00007fe7c0cc3980(0000) GS:ffff95ea8ee80000(0000) knlGS:0000000000000000 [ 156.426083] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 156.431819] CR2: 00000000000006c2 CR3: 00000003092fc005 CR4: 0000000000770ee0 [ 156.438944] PKRU: 55555554 [ 156.441647] Call Trace: [ 156.444096] [ 156.446199] pci_device_shutdown+0x38/0x60 [ 156.450297] device_shutdown+0x163/0x210 [ 156.454215] kernel_restart+0x12/0x70 [ 156.457872] __do_sys_reboot+0x1ab/0x230 [ 156.461789] ? vfs_writev+0xa6/0x1a0 [ 156.465362] ? __pfx_file_free_rcu+0x10/0x10 [ 156.469635] ? __call_rcu_common.constprop.85+0x109/0x5a0 [ 156.475034] do_syscall_64+0x3e/0x90 [ 156.478611] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 156.483658] RIP: 0033:0x7fe7bff37ab7
Vulnerabilidad en kernel de Linux (CVE-2023-53115)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: corrige fugas de memoria en mpi3mr_init_ioc() No vuelva a asignar memoria cuando se reinicialice IOC.
Vulnerabilidad en kernel de Linux (CVE-2023-53116)
Severidad: ALTA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: evitar posible UAF en nvmet_req_complete(). La implementación de la operación nvme target ->queue_response() puede liberar la solicitud pasada como argumento. Esta implementación podría provocar un use after free del puntero de solicitud al llamar a percpu_ref_put() en nvmet_req_complete(). Para evitar este problema, utilice una variable local para guardar el puntero sq antes de llamar a __nvmet_req_complete(), evitando así la desreferenciación del puntero req después de esa llamada.
Vulnerabilidad en kernel de Linux (CVE-2023-53117)
Severidad: ALTA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs: evitar la especulación de matrices fuera de los límites al cerrar un descriptor de archivo Google-Bug-Id: 114199369
Vulnerabilidad en kernel de Linux (CVE-2023-53118)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: Se corrige una regresión de eliminación del directorio del host procfs. scsi_proc_hostdir_rm() disminuye un contador de referencias y, por lo tanto, solo debe llamarse una vez por cada host eliminado. Este cambio no requiere modificar scsi_add_host_with_dma(), ya que scsi_add_host_with_dma() devolverá 0 (éxito) si se llama a scsi_proc_host_add().
Vulnerabilidad en kernel de Linux (CVE-2023-53119)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: pn533: inicializar correctamente la estructura pn533_out_arg. La estructura pn533_out_arg, utilizada como contexto temporal para out_urb, no se inicializa correctamente. Su campo "phy" no inicializado puede desreferenciarse en casos de error dentro de la función de devolución de llamada pn533_out_complete(). Provoca el siguiente error: fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 0 Comm: swapper/1 No contaminado 6.2.0-rc3-next-20230110-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 26/10/2022 RIP: 0010:pn533_out_complete.cold+0x15/0x44 drivers/nfc/pn533/usb.c:441 Rastreo de llamadas: __usb_hcd_giveback_urb+0x2b6/0x5c0 drivers/usb/core/hcd.c:1671 usb_hcd_giveback_urb+0x384/0x430 drivers/usb/core/hcd.c:1754 dummy_timer+0x1203/0x32d0 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0x1da/0x800 kernel/time/timer.c:1700 expire_timers+0x234/0x330 kernel/time/timer.c:1751 __run_timers kernel/time/timer.c:2022 [inline] __run_timers kernel/time/timer.c:1995 [inline] run_timer_softirq+0x326/0x910 kernel/time/timer.c:2035 __do_softirq+0x1fb/0xaf6 kernel/softirq.c:571 invoke_softirq kernel/softirq.c:445 [inline] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650 irq_exit_rcu+0x9/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x97/0xc0 arch/x86/kernel/apic/apic.c:1107 Inicializa el campo con el pn533_usb_phy utilizado actualmente. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.
Vulnerabilidad en kernel de Linux (CVE-2023-53120)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: Se corrige la pérdida de memoria DMA en la página de configuración. Una solución para: DMA-API: pci 0000:83:00.0: el controlador del dispositivo tiene asignaciones DMA pendientes mientras se libera del dispositivo [count=1]
Vulnerabilidad en kernel de Linux, (CVE-2023-53121)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: tcp_make_synack() se puede llamar desde el contexto del proceso. tcp_rtx_synack() ahora se puede llamar en el contexto del proceso como se explica en 0a375c822497 ("tcp: tcp_rtx_synack() se puede llamar desde el contexto del proceso"). tcp_rtx_synack() podría llamar a tcp_make_synack(), que tocará las variables por CPU con la preempción habilitada. Esto provoca el siguiente ERROR: ERROR: uso de __this_cpu_add() en código preemptible [00000000]: El llamador de ThriftIO1/5464 es tcp_make_synack+0x841/0xac0 Rastreo de llamadas: dump_stack_lvl+0x10d/0x1a0 check_preemption_disabled+0x104/0x110 tcp_make_synack+0x841/0xac0 tcp_v6_send_synack+0x5c/0x450 tcp_rtx_synack+0xeb/0x1f0 inet_rtx_syn_ack+0x34/0x60 tcp_check_req+0x3af/0x9e0 tcp_rcv_state_process+0x59b/0x2030 tcp_v6_do_rcv+0x5f5/0x700 release_sock+0x3a/0xf0 tcp_sendmsg+0x33/0x40 ____sys_sendmsg+0x2f2/0x490 __sys_sendmsg+0x184/0x230 do_syscall_64+0x3d/0x90 Evite llamar a __TCP_INC_STATS(), ya que afectará las variables por CPU. Use TCP_INC_STATS(), que se puede llamar de forma segura desde un cambio de contexto.
Vulnerabilidad en kernel de Linux (CVE-2023-53123)
Severidad: ALTA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: s390: Se corrige el problema de use-after-free de recursos PCI con la conexión en caliente por función. En s390, las funciones PCI pueden conectarse en caliente individualmente, incluso si pertenecen a un dispositivo multifunción. En particular, en un dispositivo SR-IOV, las funciones virtuales (VF) pueden eliminarse y volver a añadirse posteriormente. Sin embargo, en el commit a50297cf8235 ("s390/pci: separar la creación de zbus del escaneo") se omitió que la lista de recursos de struct pci_bus y struct zpci_bus conservaba una referencia a los recursos MMIO de las funciones PCI, incluso si estos recursos se liberan al desconectar en caliente. Estos recursos obsoletos pueden reclamarse posteriormente cuando la función PCI reaparece, lo que resulta en un problema de use-after-free. Una idea para corregir este problema de use-after-free en el código específico de s390 que se investigó fue simplemente mantener los recursos desde el momento en que aparece una función PCI hasta que desaparece todo el bus PCI virtual creado para un dispositivo multifunción. El problema con esto, sin embargo, es que debido al requisito de direcciones MMIO artificiales (cookies de dirección), se necesita lógica adicional para mantener las cookies de dirección compatibles al volver a conectar. Al mismo tiempo, los recursos MMIO pertenecen semánticamente a la función PCI, por lo que vincular su ciclo de vida a la función parece más lógico. En cambio, un enfoque más simple es eliminar los recursos de una función PCI individualmente desconectada en caliente de la lista de recursos del bus PCI, mientras que se mantienen intactos los recursos de otras funciones PCI en el bus PCI. Esto se hace introduciendo pci_bus_remove_resource() para eliminar un recurso individual. De manera similar, el recurso también debe eliminarse de la lista de recursos de struct zpci_bus. Sin embargo, resulta que realmente no hay necesidad de agregar los recursos MMIO a la lista de recursos de struct zpci_bus en absoluto y, en su lugar, podemos simplemente usar el puntero de recursos de zpci_bar_struct directamente.
Vulnerabilidad en kernel de Linux (CVE-2023-53124)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpt3sas: Se corrige el acceso a puntero nulo en mpt3sas_transport_port_add(). El puerto se asigna mediante sas_port_alloc_num() y el rphy se asigna mediante sas_end_device_alloc() o sas_expander_alloc(), lo que puede devolver un valor nulo. Por lo tanto, es necesario comprobar el rphy para evitar un posible acceso a puntero nulo. Si sas_rphy_add() falla, el rphy se establece en nulo. Accederíamos al rphy en las siguientes líneas, lo que también resultaría en un acceso a puntero nulo.
Vulnerabilidad en kernel de Linux (CVE-2023-53125)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: usb: smsc75xx: Limitar la longitud del paquete a skb->len. La longitud del paquete recuperada de los datos de skb puede ser mayor que la longitud real del búfer del socket (hasta 9026 bytes). En tal caso, el skb clonado que se pasa a la pila de red filtrará el contenido de la memoria del kernel.
Vulnerabilidad en kernel de Linux (CVE-2025-37920)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: Corrige la condición de ejecución en la ruta RX genérica AF_XDP Mueve rx_lock de xsk_socket a xsk_buff_pool. Corrige la sincronización para el modo umem compartido en la ruta RX genérica donde varios sockets comparten un solo xsk_buff_pool. La cola RX es exclusiva de xsk_socket, mientras que la cola FILL se puede compartir entre varios sockets. Esto podría resultar en una condición de ejecución donde dos núcleos de CPU acceden a la ruta RX de dos sockets diferentes que comparten el mismo umem. Protege ambas colas adquiriendo spinlock en xsk_buff_pool compartido. La contención de bloqueos se puede minimizar en el futuro mediante algún búfer FQ por subproceso. Es seguro y necesario mover spin_lock_bh(rx_lock) después de xsk_rcv_check(): * xs->pool y spinlock_init se sincronizan mediante barreras de memoria xsk_bind() -> xsk_is_bound(). * xsk_rcv_check() puede devolver verdadero al ejecutar xsk_release() o xsk_unbind_dev(); sin embargo, esto no causará ejecucións de datos ni condiciones de ejecución. xsk_unbind_dev() elimina el socket xdp de todos los mapas y espera a que se completen todas las operaciones de recepción pendientes. Los paquetes en la ruta de recepción se completarán correctamente o se descartarán.
Vulnerabilidad en kernel de Linux (CVE-2025-37921)
Severidad: ALTA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vxlan: vnifilter: Se corrige la eliminación desbloqueada de la entrada FDB predeterminada. Cuando se elimina una VNI de un dispositivo VXLAN en modo 'vnifilter', la entrada FDB asociada al control remoto predeterminado (si se configuró uno) se elimina sin mantener el bloqueo hash. Esto es incorrecto y generará una advertencia [1] generada por la anotación lockdep, añadida por el commit ebe642067455 ("vxlan: Crear envoltorios para la búsqueda FDB"). Reproductor: # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0 # bridge vni del vni 10010 dev vx0 Se corrige adquiriendo el bloqueo hash antes de la eliminación y liberándolo después. Culpe a el commit original que introdujo el problema en lugar de a la que lo expuso. [1] ADVERTENCIA: CPU: 3 PID: 392 en drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0 [...] RIP: 0010:vxlan_find_mac+0x17f/0x1a0 [...] Rastreo de llamadas: __vxlan_fdb_delete+0xbe/0x560 vxlan_vni_delete_group+0x2ba/0x940 vxlan_vni_del.isra.0+0x15f/0x580 vxlan_process_vni_filter+0x38b/0x7b0 vxlan_vnifilter_process+0x3bb/0x510 rtnetlink_rcv_msg+0x2f7/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Vulnerabilidad en kernel de Linux (CVE-2025-37922)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: book3s64/radix : Alinear la dirección de inicio de la sección vmemmap a PAGE_SIZE Un altmap de vmemmap es una región proporcionada por el dispositivo que se utiliza para proporcionar almacenamiento de respaldo para páginas de estructura. Para cada espacio de nombres, el altmap debe pertenecer a ese mismo espacio de nombres. Si los espacios de nombres se crean sin alinear, existe la posibilidad de que la dirección de inicio de la sección vmemmap también esté desalineada. Si la dirección de inicio de la sección vmemmap no está alineada, la página altmap asignada desde el espacio de nombres actual también podría ser utilizada por el espacio de nombres anterior. Durante la operación de liberación, dado que el altmap se comparte entre dos espacios de nombres, el espacio de nombres anterior puede detectar que la página no pertenece a su altmap y asumir incorrectamente que la página es una página normal. Entonces intenta liberar la página normal, lo que provoca un fallo del kernel. El kernel intentó leer la página del usuario (18): ¿intento de explotación? (uid: 0) ERROR: Desreferencia de puntero NULL del kernel en lectura en 0x00000018 Dirección de instrucción con errores: 0xc000000000530c7c Oops: Acceso del kernel al área incorrecta, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries CPU: 32 PID: 2104 Comm: ndctl Kdump: cargado Contaminado: GW NIP: c000000000530c7c LR: c000000000530e00 CTR: 0000000000007ffe REGS: c000000015e57040 TRAP: 0300 Contaminado: GW MSR: 800000000280b033 CR: 84482404 CFAR: c000000000530dfc DAR: 00000000000000018 DSISR: 40000000 IRQMASK: 0 GPR00: c000000000530e00 c000000015e572e0 c000000002c5cb00 c00c000101008040 GPR04: 00000000000000000 0000000000000007 0000000000000001 0000000000000001f GPR08: 0000000000000005 0000000000000000 0000000000000018 0000000000002000 GPR12: c0000000001d2fb0 c0000060de6b0080 0000000000000000 c0000060dbf90020 GPR16: c00c000101008000 0000000000000001 000000000000000 c000000125b20f00 GPR20: 0000000000000001 0000000000000000 ffffffffffffffff c00c000101007fff GPR24: 0000000000000001 0000000000000000 0000000000000000 0000000000000000 GPR28: 0000000004040201 000000000000001 000000000000000 c00c000101008040 NIP [c000000000530c7c] máscara_obtener_indicadores_pfnblock+0x7c/0xd0 LR [c000000000530e00] free_unref_page_prepare+0x130/0x4f0 Rastreo de llamadas: free_unref_page+0x50/0x1e0 free_reserved_page+0x40/0x68 free_vmemmap_pages+0x98/0xe0 remove_pte_table+0x164/0x1e8 remove_pmd_table+0x204/0x2c8 remove_pud_table+0x1c4/0x288 remove_pagetable+0x1c8/0x310 vmemmap_free+0x24/0x50 section_deactivate+0x28c/0x2a0 __remove_pages+0x84/0x110 arch_remove_memory+0x38/0x60 Otro problema es que si no hay un altmap, se asignará una página vmemmap del tamaño de PMD desde la RAM, independientemente de la alineación de la dirección de inicio de la sección. Si la dirección de inicio de la sección no está alineada con el tamaño de PMD, se activará un error VM_BUG_ON al configurar la página de tamaño PMD en la tabla de páginas. En esta revisión, estamos alineando la dirección de inicio de vmemmap de la sección con PAGE_SIZE. Después de la alineación, la dirección de inicio no formará parte del espacio de nombres actual y se asignará una página normal para la asignación de vmemmap de la sección actual. Para las secciones restantes, se asignarán mapas alternativos. Durante la operación de liberación, la página normal se liberará correctamente. De la misma manera, se asignará una página vmemmap PMD_SIZE solo si la dirección de inicio de la sección está alineada con PMD_SIZE; de lo contrario, se recurrirá a una asignación de vmemmap de tamaño PAGE. Sin esta revisión ===================== Inicio de NS1 Inicio de NS2 _________________________________________________________ | NS1 | NS2 | --------------------------------------------------------- | Altmap| Altmap | .....|Altmap| Altmap | ........... | NS1 | NS1 ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2025-37923)
Severidad: ALTA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: Se corrige la escritura fuera de los límite en trace_seq_to_buffer() syzbot informó este error: ====================================================================== ERROR: KASAN: slab-out-of-bounds en trace_seq_to_buffer kernel/trace/trace.c:1830 [en línea] ERROR: KASAN: slab-out-of-bounds en tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 Escritura de tamaño 4507 en la dirección ffff888032b6b000 por tarea syz.2.320/7260 CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 No contaminado 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full) Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [en línea] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [en línea] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106 trace_seq_to_buffer kernel/trace/trace.c:1830 [en línea] tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 .... ===================================================================== Se ha informado que trace_seq_to_buffer() intenta copiar más datos que PAGE_SIZE a buf. Por lo tanto, para evitarlo, debemos usar el valor menor entre trace_seq_used(&iter->seq) y PAGE_SIZE como argumento.
Vulnerabilidad en kernel de Linux (CVE-2025-37924)
Severidad: ALTA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: corrección del use-after-free en la autenticación Kerberos. Se introdujo la configuración sess->user = NULL para corregir el puntero colgante creado por ksmbd_free_user. Sin embargo, es posible que otro hilo esté operando en la sesión y utilice sess->user después de que se haya pasado a ksmbd_free_user, pero antes de que sess->user se establezca en NULL.
Vulnerabilidad en kernel de Linux (CVE-2025-37926)
Severidad: ALTA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige el problema de use-after-free en ksmbd_session_rpc_open. Un problema de UAF puede ocurrir debido a una condición de ejecución entre ksmbd_session_rpc_open() y __session_rpc_close(). Agregue rpc_lock a la sesión para protegerla.
Vulnerabilidad en kernel de Linux (CVE-2025-37927)
Severidad: ALTA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/amd: Arreglar desbordamiento de búfer potencial en parse_ivrs_acpihid Hay un error de lógica de análisis de cadenas que puede provocar un desbordamiento de los búferes hid o uid. La comparación de ACPIID_LEN con la longitud total de una cadena no tiene en cuenta las longitudes de los búferes hid y uid individuales, por lo que la comprobación es insuficiente en algunos casos. Por ejemplo, si la longitud de la cadena hid es 4 y la longitud de la cadena uid es 260, la longitud de str será igual a ACPIID_LEN + 1, pero la cadena uid desbordará el búfer uid, cuyo tamaño es 256. Lo mismo se aplica a la cadena hid con una longitud de 13 y a la cadena uid con una longitud de 250. Compruebe la longitud de las cadenas hid y uid por separado para evitar el desbordamiento del búfer. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.
Vulnerabilidad en kernel de Linux (CVE-2025-37928)
Severidad: ALTA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm-bufio: no programar en contexto atómico Se informó un ERROR como el siguiente cuando CONFIG_DEBUG_ATOMIC_SLEEP y try_verify_in_tasklet están habilitados. [ 129.444685][ T934] ERROR: función de suspensión llamada desde un contexto no válido en drivers/md/dm-bufio.c:2421 [ 129.444723][ T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4 [ 129.444740][ T934] preempt_count: 201, esperado: 0 [ 129.444756][ T934] Profundidad de anidamiento de RCU: 0, esperado: 0 [ 129.444781][ T934] Preempción deshabilitada en: [ 129.444789][ T934] [] shrink_work+0x21c/0x248 [ 129.445167][ T934] ¡ERROR del kernel en kernel/sched/walt/walt_debug.c:16! [ 129.445183][ T934] Error interno: Ups - BUG: 00000000f2000800 [#1] PREEMPT SMP [ 129.445204][ T934] Omitir volcado de búfer de md ftrace para: 0x1609e0 [ 129.447348][ T934] CPU: 1 PID: 934 Comm: kworker/1:4 Contaminado: GW OE 6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8 [ 129.447362][ T934] Nombre del hardware: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT) [ 129.447373][ T934] Cola de trabajo: dm_bufio_cache shrink_work [ 129.447394][ T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 129.447406][ T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug] [ 129.447435][ T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c [ 129.447451][ T934] sp : ffffffc0843dbc90 [ 129.447459][T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b [ 129.447479][T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68 [ 129.447497][ T934] x23: ffffff805171c5b4 x22: 00000000000000000 x21: ffffffd816231900 [ 129.447517][T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030 [ 129.447535][ T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358 [ 129.447554][ T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003 [ 129.447572][ T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9: 7e779c5735de9400 [129.447591][T934] x8: ffffffd81560d004 x7: 205b5d3938373434 x6: ffffffd8167397c8 [ 129.447610][T934] x5: 0000000000000000 x4: 0000000000000001 x3: ffffffc0843db9e0 [129.447629][T934] x2: 0000000000002f15 x1: 0000000000000000 x0 : 0000000000000000 [ 129.447647][ T934] Rastreo de llamadas: [ 129.447655][ T934] android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6] [ 129.447681][ T934] __might_resched+0x190/0x1a8 [ 129.447694][ T934] shrink_work+0x180/0x248 [ 129.447706][ T934] proceso_uno_trabajo+0x260/0x624 [ 129.447718][ T934] subproceso_de_trabajo+0x28c/0x454 [ 129.447729][ T934] subproceso_de_trabajo+0x118/0x158 [ 129.447742][ T934] ret_de_bifurcación+0x10/0x20 [ 129.447761][ T934] Código: ???????? ???????? ???????? d2b5dd1f (d4210000) [ 129.447772][ T934] ---[ fin del seguimiento 0000000000000000 ]--- dm_bufio_lock llamará a spin_lock_bh cuando try_verify_in_tasklet esté habilitado, y se llamará a __scan en el contexto atómico.
Vulnerabilidad en kernel de Linux (CVE-2025-37929)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: errata: Añadir centinelas faltantes a las matrices MIDR de Spectre-BHB. El commit a5951389e58d ("arm64: errata: Añadir nuevos núcleos ARM a las listas spectre_bhb_loop_affected()") añadió CPU adicionales a la solución alternativa de Spectre-BHB, incluyendo nuevas matrices para diseños que requieren nuevos valores 'k' para que la solución sea efectiva. Desafortunadamente, las nuevas matrices omitieron la entrada de centinela, por lo que is_midr_in_range_list() se desviará al final si no encuentra una coincidencia. Con UBSAN habilitado, esto provoca un fallo durante el arranque cuando is_midr_in_range_list() está en línea (lo cual era más común antes de c8c2647e69be ("arm64: Convertir _midr_in_range_list() en una función exportada")): | Error interno: aarch64 BRK: 00000000f2000001 [#1] PREEMPT SMP | pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : spectre_bhb_loop_affected+0x28/0x30 | lr : is_spectre_bhb_affected+0x170/0x190 | [...] | Rastreo de llamadas: | spectre_bhb_loop_affected+0x28/0x30 | update_cpu_capabilities+0xc0/0x184 | init_cpu_features+0x188/0x1a4 | cpuinfo_store_boot_cpu+0x4c/0x60 | smp_prepare_boot_cpu+0x38/0x54 | start_kernel+0x8c/0x478 | __primary_switched+0xc8/0xd4 | Código: 6b09011f 54000061 52801080 d65f03c0 (d4200020) | ---[ fin del seguimiento 000000000000000 ]--- | Pánico del kernel - no sincroniza: aarch64 BRK: Excepción fatal Agregue las entradas centinela faltantes.
Vulnerabilidad en kernel de Linux (CVE-2025-37930)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau: Corrección de WARN_ON en nouveau_fence_context_kill(). Nouveau está diseñado principalmente de tal manera que se espera que las vallas solo se señalicen mediante nouveau_fence_signal(). Sin embargo, en al menos otro lugar, nouveau_fence_done(), también puede señalizar vallas. Si esto sucede (ejecución), una valla señalizada permanece en la lista de pendientes durante un tiempo, hasta que nouveau_fence_update() la elimina. Si nouveau_fence_context_kill() se ejecuta mientras tanto, esto sería un error porque la función intentaría establecer un código de error en una valla ya señalizada. Haga que nouveau_fence_context_kill() compruebe si hay una valla señalizada.
Vulnerabilidad en Chaitak-gorai Blogbook (CVE-2025-5400)
Severidad: MEDIA
Fecha de publicación: 01/06/2025
Fecha de última actualización: 10/11/2025
Se encontró una vulnerabilidad en Chaitak-gorai Blogbook hasta la versión 92f5cf90f8a7e6566b576fe0952e14e1c6736513. Se ha clasificado como crítica. Se ve afectada una función desconocida del archivo /user.php del componente GET Parameter Handler. La manipulación del argumento u_id provoca una inyección SQL. Es posible ejecutar el ataque de forma remota. Se ha hecho público el exploit y puede que sea utilizado. Este producto utiliza una versión continua para una distribución continua. Por lo tanto, no se dispone de detalles de las versiones afectadas ni de las actualizaciones. Se contactó al proveedor con antelación sobre esta divulgación, pero no respondió.
Vulnerabilidad en Chaitak-gorai Blogbook (CVE-2025-5401)
Severidad: MEDIA
Fecha de publicación: 01/06/2025
Fecha de última actualización: 10/11/2025
Se encontró una vulnerabilidad en Chaitak-gorai Blogbook hasta la versión 92f5cf90f8a7e6566b576fe0952e14e1c6736513. Se ha declarado crítica. Esta vulnerabilidad afecta a una funcionalidad desconocida del archivo /post.php del componente GET Parameter Handler. La manipulación del argumento p_id provoca una inyección SQL. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado. Este producto utiliza el enfoque de lanzamiento continuo para garantizar una entrega continua. Por lo tanto, no se dispone de detalles de las versiones afectadas ni de las actualizadas. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
Vulnerabilidad en Chaitak-gorai Blogbook (CVE-2025-5402)
Severidad: MEDIA
Fecha de publicación: 01/06/2025
Fecha de última actualización: 10/11/2025
Se encontró una vulnerabilidad en Chaitak-gorai Blogbook hasta la versión 92f5cf90f8a7e6566b576fe0952e14e1c6736513. Se ha clasificado como crítica. Este problema afecta a una funcionalidad desconocida del archivo /admin/includes/edit_post.php del componente GET Parameter Handler. La manipulación del argumento edit_post_id provoca una inyección SQL. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado. Este producto utiliza un sistema de entrega continua con versiones continuas. Por lo tanto, no se dispone de detalles de las versiones afectadas ni de las versiones actualizadas. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
Vulnerabilidad en Chaitak-gorai Blogbook (CVE-2025-5403)
Severidad: MEDIA
Fecha de publicación: 01/06/2025
Fecha de última actualización: 10/11/2025
Se ha detectado una vulnerabilidad clasificada como crítica en Chaitak-gorai Blogbook hasta la versión 92f5cf90f8a7e6566b576fe0952e14e1c6736513. Esta vulnerabilidad afecta a una parte desconocida del archivo /admin/view_all_posts.php del componente GET Parameter Handler. La manipulación del argumento post_id provoca una inyección SQL. Es posible iniciar el ataque de forma remota. Se ha hecho público el exploit y puede que sea utilizado. Este producto no utiliza control de versiones. Por ello, no se dispone de información sobre las versiones afectadas y no afectadas. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
Vulnerabilidad en Chaitak-gorai Blogbook (CVE-2025-5404)
Severidad: MEDIA
Fecha de publicación: 01/06/2025
Fecha de última actualización: 10/11/2025
Se encontró una vulnerabilidad clasificada como problemática en Chaitak-gorai Blogbook hasta la versión 92f5cf90f8a7e6566b576fe0952e14e1c6736513. Esta vulnerabilidad afecta al código desconocido del archivo /search.php del componente GET Parameter Handler. La manipulación del argumento "Search" provoca una denegación de servicio. Se ha hecho público el exploit y puede que sea utilizado. Este producto utiliza una versión continua para ofrecer una entrega continua. Por lo tanto, no se dispone de detalles de las versiones afectadas ni de las actualizaciones. Se contactó al proveedor con antelación sobre esta divulgación, pero no respondió.
Vulnerabilidad en chaitak-gorai Blogbook (CVE-2025-5405)
Severidad: MEDIA
Fecha de publicación: 01/06/2025
Fecha de última actualización: 10/11/2025
Se ha detectado una vulnerabilidad clasificada como problemática en chaitak-gorai Blogbook hasta la versión 92f5cf90f8a7e6566b576fe0952e14e1c6736513. Este problema afecta a un procesamiento desconocido del archivo /post.php. La manipulación del argumento comment_author/comment_email/comment_content provoca cross-site-scripting. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado. Este producto utiliza el enfoque de versiones continuas para garantizar una entrega continua. Por lo tanto, no se dispone de detalles de las versiones afectadas ni de las actualizadas. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
Vulnerabilidad en Chaitak-gorai Blogbook (CVE-2025-5406)
Severidad: MEDIA
Fecha de publicación: 01/06/2025
Fecha de última actualización: 10/11/2025
Se encontró una vulnerabilidad clasificada como crítica en Chaitak-gorai Blogbook hasta la versión 92f5cf90f8a7e6566b576fe0952e14e1c6736513. Se ve afectada una función desconocida del archivo /admin/posts.php?source=add_post. La manipulación del argumento "image" permite la carga sin restricciones. Es posible ejecutar el ataque de forma remota. Se ha hecho público el exploit y puede que sea utilizado. Este producto utiliza un sistema de entrega continua con versiones continuas. Por lo tanto, no se dispone de detalles de las versiones afectadas ni de versiones actualizadas. Se contactó al proveedor con antelación sobre esta divulgación, pero no respondió.
Vulnerabilidad en Chaitak-gorai Blogbook (CVE-2025-5407)
Severidad: MEDIA
Fecha de publicación: 01/06/2025
Fecha de última actualización: 10/11/2025
Se ha encontrado una vulnerabilidad en Chaitak-gorai Blogbook hasta la versión 92f5cf90f8a7e6566b576fe0952e14e1c6736513, clasificada como problemática. Esta vulnerabilidad afecta a una funcionalidad desconocida del archivo /register_script.php. La manipulación del argumento fullname provoca cross-site-scripting. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado. Este producto no utiliza control de versiones. Por ello, no hay información disponible sobre las versiones afectadas y no afectadas. Se recomienda actualizar el componente afectado. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
Vulnerabilidad en RaspAP raspap-webgui 3.3.1 (CVE-2025-44163)
Severidad: MEDIA
Fecha de publicación: 27/06/2025
Fecha de última actualización: 10/11/2025
RaspAP raspap-webgui 3.3.1 es vulnerable a Directory Traversal en ajax/networking/get_wgkey.php. Un atacante autenticado puede enviar una solicitud POST manipulada con un payload de path traversal en el parámetro `entity` para sobrescribir archivos arbitrarios con permisos de escritura del servidor web mediante el uso indebido del comando `tee` utilizado en la ejecución del shell.
Vulnerabilidad en Youki (CVE-2025-54867)
Severidad: ALTA
Fecha de publicación: 14/08/2025
Fecha de última actualización: 10/11/2025
Youki es un entorno de ejecución de contenedores escrito en Rust. Antes de la versión 0.5.5, si /proc y /sys en rootfs eran enlaces simbólicos, podían explotarse para acceder al sistema de archivos raíz del host. Este problema se ha corregido en la versión 0.5.5.