Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwpoison, memory_hotplug: bloquear folio antes de desasignar folio hwpoisoned Commit b15c87263a69 ("hwpoison, memory_hotplug: permitir que las páginas hwpoisoned se desconecten") añadir comprobaciones de envenenamiento de página en do_migrate_range para posibilitar la desconexión de la página hwpoisoned mediante la introducción de insulation_lru_page y try_to_unmap para la página hwpoisoned. Sin embargo, el bloqueo de folio debe mantenerse antes de llamar a try_to_unmap. Añadir esto para solucionar este problema. Se producirá una advertencia si el folio no se bloquea durante la desasignación: ------------[ cortar aquí ]------------ ¡ERROR del kernel en ./include/linux/swapops.h:400! Error interno: Oops - ERROR: 00000000f2000800 [#1] PREEMPT Módulos SMP vinculados en: CPU: 4 UID: 0 PID: 411 Comm: bash Contaminado: GW 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Contaminado: [W]=WARN Nombre del hardware: QEMU Máquina virtual QEMU, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Rastreo de llamadas: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invocar_llamada_al_sistema+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Código: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethtool: netlink: Permite nlattrs nulos al obtener un phy_device. ethnl_req_get_phydev() se usa para buscar un phy_device si el comando netlink de ethtool apunta a un phydev específico dentro de la topología de un netdev. Toma como parámetro una constante struct nlattr *header que se usa para la gestión de errores: if (!phydev) { NL_SET_ERR_MSG_ATTR(extack, header, "no phy matches phyindex"); return ERR_PTR(-ENODEV); } Sin embargo, en la ruta de notificación después de una operación ->set, no hay atributos de solicitud disponibles. El sitio de llamada típico para la función anterior se ve así: phydev = ethnl_req_get_phydev(req_base, tb[ETHTOOL_A_XXX_HEADER], info->extack); Por lo tanto, cuando tb es nulo (como en la ruta de notificación de ethnl), se produce un fallo. Resulta que solo el comando PLCA se encuentra en ese caso, ya que los demás comandos específicos de phydev no tienen notificación. Esta confirmación corrige el fallo pasando el índice cmd y la matriz nlattr por separado, lo que permite comprobar su estado nulo directamente dentro del asistente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cdx: Se corrige un posible error de UAF en driver_override_show() Se corrigió un posible problema de UAF en driver_override_show() en drivers/cdx/cdx.c Esta función driver_override_show() es parte de DEVICE_ATTR_RW, que incluye tanto driver_override_show() como driver_override_store(). Estas funciones se pueden ejecutar simultáneamente en sysfs. La función driver_override_store() usa driver_set_override() para actualizar el valor de driver_override, y driver_set_override() bloquea internamente el dispositivo (device_lock(dev)). Si driver_override_show() lee cdx_dev->driver_override sin bloquear, podría acceder potencialmente a un puntero liberado si driver_override_store() libera la cadena simultáneamente. Esto podría llevar a imprimir una dirección del kernel, lo cual es un riesgo de seguridad ya que DEVICE_ATTR puede ser leído por todos los usuarios. Además, se utiliza un patrón similar en drivers/amba/bus.c, así como en muchos otros controladores de bus, donde device_lock() se utiliza en la función show y ha funcionado sin problemas. Este posible error fue detectado por nuestra herramienta experimental de análisis estático, que analiza las API de bloqueo y las funciones emparejadas para identificar carreras de datos y violaciones de atomicidad.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: atm: cxacru: corrige un fallo en las comprobaciones de endpoints existentes Syzbot volvió a identificar un fallo en la comprobación de endpoints USB, consulte [1]. Esta vez, el problema se debe a una confirmación de mi autoría (2eabb655a968 ("usb: atm: cxacru: fix endpoint checking in cxacru_bind()")). Si bien usar usb_find_common_endpoints() suele ser suficiente para descartar dispositivos con endpoints erróneos, en este caso se necesita más que simplemente encontrar e identificar la cantidad suficiente de endpoints de los tipos correctos: también se necesita comprobar la dirección del endpoint. Dado que cxacru_bind() rellena las URB teniendo en cuenta la dirección CXACRU_EP_CMD, cambie el enfoque de verificación de endpoints a usb_check_XXX_endpoints() para corregir las pruebas de EP incompletas. [1] Informe de Syzbot: usb 5-1: transferencia de urb FALSA, canal 3 != tipo 1 ADVERTENCIA: CPU: 0 PID: 1378 en drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... RIP: 0010:usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Seguimiento de llamadas cxacru_cm+0x3c8/0xe50 drivers/usb/atm/cxacru.c:649 cxacru_card_status drivers/usb/atm/cxacru.c:760 [inline] cxacru_bind+0xcf9/0x1150 drivers/usb/atm/cxacru.c:1223 usbatm_usb_probe+0x314/0x1d30 drivers/usb/atm/usbatm.c:1058 cxacru_usb_probe+0x184/0x220 drivers/usb/atm/cxacru.c:1377 usb_probe_interface+0x641/0xbb0 drivers/usb/core/driver.c:396 really_probe+0x2b9/0xad0 drivers/base/dd.c:658 __driver_probe_device+0x1a2/0x390 drivers/base/dd.c:800 driver_probe_device+0x50/0x430 drivers/base/dd.c:830 ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: renesas_usbhs: Borrar la función notify_hotplug_work. Al realizar operaciones continuas de desvinculación/vinculación en los controladores USB disponibles en el SoC Renesas RZ/G2L, puede producirse un fallo del kernel con el mensaje "No se puede gestionar la desreferencia del puntero nulo del kernel en la dirección virtual". Este problema afecta a la función usbhsc_notify_hotplug(). Borre la función retrasada para evitar su ejecución cuando los recursos del controlador no estén disponibles.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: ucsi: Se corrige el acceso a punteros nulos. Los recursos solo deben liberarse después de que se hayan destruido todos los subprocesos que los utilizan. Esta confirmación garantiza que los recursos no se liberen prematuramente esperando a que se complete la cola de trabajo asociada antes de desasignarlos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/fair: Se corrige la posible corrupción de memoria en child_cfs_rq_on_list. child_cfs_rq_on_list intenta convertir un puntero 'prev' en un cfs_rq. Este puntero 'prev' puede originarse en leaf_cfs_rq_list de struct rq, invalidando la conversión y potencialmente provocando corrupción de memoria. Dependiendo de las posiciones relativas de leaf_cfs_rq_list y el puntero del grupo de tareas (tg) dentro de la estructura, esto puede causar un fallo de memoria o acceder a datos basura. El problema surge en list_add_leaf_cfs_rq, donde tanto cfs_rq->leaf_cfs_rq_list como rq->leaf_cfs_rq_list se añaden a la misma lista de hojas. Además, rq->tmp_alone_branch puede establecerse en rq->leaf_cfs_rq_list. Esto añade una comprobación `if (prev == &rq->leaf_cfs_rq_list)` después de la condición principal en child_cfs_rq_on_list. Esto garantiza que la operación container_of convierta una estructura cfs_rq correcta. Esta comprobación es suficiente porque solo se añaden a la lista las cfs_rqs en la misma CPU, por lo que basta con verificar el puntero `prev` con la cabecera de la lista de la rq actual. Corrige un posible problema de corrupción de memoria que, debido al diseño actual de la estructura, podría no manifestarse como un fallo, pero podría provocar un comportamiento impredecible al cambiar el diseño.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vlan: imponer el tipo de dispositivo subyacente Actualmente, los dispositivos VLAN se pueden crear sobre dispositivos que no sean Ethernet. Además del hecho de que no tiene mucho sentido, esto también causa un error que filtra la dirección de una función del kernel al modo de usuario. Al crear un dispositivo VLAN, inicializamos GARP (garp_init_applicant) y MRP (mrp_init_applicant) para el dispositivo subyacente. Como parte del proceso de inicialización, agregamos la dirección de multidifusión de cada solicitante al dispositivo subyacente, llamando a dev_mc_add. __dev_mc_add usa dev->addr_len para determinar la longitud de la nueva dirección de multidifusión. Esto causa una lectura fuera de los límites si dev->addr_len es mayor que 6, ya que las direcciones de multidifusión proporcionadas por GARP y MRP solo tienen 6 bytes de longitud. Este comportamiento se puede reproducir utilizando los siguientes comandos: ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vlan id 100 Luego, el siguiente comando mostrará la dirección de garp_pdu_rcv: ip maddr show | grep 01:80:c2:00:00:21 Corrija el error aplicando el tipo de dispositivo subyacente durante la inicialización del dispositivo VLAN.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ppp: Corrección de la advertencia de valor no inicializado de KMSAN con bpf. Syzbot detectó una advertencia "KMSAN: valor no inicializado" [1], causada por el controlador ppp que no inicializa una cabecera de 2 bytes al usar un filtro de socket. El siguiente código puede generar un programa BPF con filtro PPP: ''' struct bpf_program fp; pcap_t *handle; handle = pcap_open_dead(DLT_PPP_PPPD, 65535); pcap_compile(handle, &fp, "ip and outbound", 0, 0); bpf_dump(&fp, 1); ''' Su salida es: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen puede encontrar código similar en el siguiente enlace: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 El fabricante de este repositorio de código también es el fabricante original del controlador ppp. Como puede ver, el programa BPF omite 2 bytes de datos y luego lee el campo 'Protocolo' para determinar si es un paquete IP. Luego lee el primer byte de los primeros 2 bytes para determinar la dirección. El problema es que solo se inicializa el primer byte que indica la dirección en el código del controlador ppp actual, mientras que el segundo byte no se inicializa. En los programas BPF normales generados por libpcap, no se utilizan datos no inicializados, por lo que no supone un problema. Sin embargo, en programas BPF cuidadosamente manipulados, como los generados por syzkaller [2], que empiezan a leer desde el desplazamiento 0, KMSAN utilizará y capturará los datos no inicializados. [1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: clean up ROC on fault () Si el firmware no inicia la protección de sesión, entonces llamamos a iwl_mvm_roc_finished() aquí, pero eso no hará nada en absoluto porque IWL_MVM_STATUS_ROC_P2P_RUNNING nunca se configuró. Establezca IWL_MVM_STATUS_ROC_P2P_RUNNING en la ruta de error/detención. Si se inició correctamente antes, ya está configurado, por lo que no importa, y si no se inició, debe configurarse para limpiar. No hacerlo conducirá a un WARN_ON() más tarde en un nuevo canal restante, ya que el enlace ya está activo cuando se activó, ya que nunca se desactivó.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: fallo de memoria: actualización del indicador ttu dentro de unmap_poisoned_folio. Serie de parches "mm: fallo de memoria: desasignar correctamente un folio envenenado durante la migración", v3. Se corrigen dos errores durante la migración de folios si este está envenenado. Este parche (de 3): El commit 6da6b1d4a7df ("mm/hwpoison: convertir TTU_IGNORE_HWPOISON en TTU_HWPOISON") introduce TTU_HWPOISON en lugar de TTU_IGNORE_HWPOISON para detener el envío de la señal SIGBUS al acceder a una página con error tras un error de memoria en un folio limpio. Sin embargo, durante la migración de páginas, anon folio debe configurarse con TTU_HWPOISON durante unmap_*(). Para la caché de páginas, necesitamos una política similar a la de hwpoison_user_mappings para configurar este indicador. Por lo tanto, mueva esta política de hwpoison_user_mappings a unmap_poisoned_folio para gestionar esta advertencia correctamente. Se producirá una advertencia durante el envenenamiento de folio de unamp con el siguiente registro: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 1 PID: 365 en mm/rmap.c:1847 try_to_unmap_one+0x8fc/0xd3c Módulos vinculados: CPU: 1 UID: 0 PID: 365 Comm: bash Contaminado: GW 6.13.0-rc1-00018-gacdb4bbda7ab #42 Contaminado: [W]=WARN Nombre del hardware: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0x8fc/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Rastreo de llamadas: try_to_unmap_one+0x8fc/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c ---[fin de seguimiento 0000000000000000 ]--- [mawupeng1@huawei.com: unmap_poisoned_folio(): eliminar el 'mapeo' local sombreado, según Miaohe] Enlace: https://lkml.kernel.org/r/20250219060653.3849083-1-mawupeng1@huawei.com

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFS: se corrige que nfs_release_folio() no se bloquee mediante la reescritura de kcompactd. Se añade el indicador PF_KCOMPACTD y el asistente current_is_kcompactd() para comprobarlo, de modo que nfs_release_folio() pueda omitir la llamada a nfs_wb_folio() desde kcompactd. De lo contrario, NFS puede bloquearse a la espera de la reescritura inducida por kcompactd, que recurre a NFS (lo que activa la reescritura en NFSD mediante el montaje de bucle invertido de NFS en el mismo host; NFSD se bloquea a la espera de la llamada de XFS a __filemap_get_folio): 6070.550357] INFORMACIÓN: la tarea kcompactd0:58 ha estado bloqueada durante más de 4435 segundos. {--- [58] "kcompactd0" [<0>] folio_wait_bit+0xe8/0x200 [<0>] folio_wait_writeback+0x2b/0x80 [<0>] nfs_wb_folio+0x80/0x1b0 [nfs] [<0>] nfs_release_folio+0x68/0x130 [nfs] [<0>] split_huge_page_to_list_to_order+0x362/0x840 [<0>] migrate_pages_batch+0x43d/0xb90 [<0>] migrate_pages_sync+0x9a/0x240 [<0>] migrate_pages+0x93c/0x9f0 [<0>] compact_zone+0x8e2/0x1030 [<0>] compact_node+0xdb/0x120 [<0>] kcompactd+0x121/0x2e0 [<0>] kthread+0xcf/0x100 [<0>] ret_from_fork+0x31/0x40 [<0>] ret_from_fork_asm+0x1a/0x30 ---} [akpm@linux-foundation.org: corrección de compilación]