Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: microchip: pci1xxxx: Resuelve el pánico del kernel durante la gestión de IRQ GPIO Resuelve el pánico del kernel causado por la gestión incorrecta de IRQ mientras se accede a valores GPIO. Esto se hace reemplazando generic_handle_irq con handle_nested_irq.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: topología: mantener la cpumask sin cambios al imprimir cpumap Durante las pruebas fuzz, se descubrió la siguiente advertencia: diferentes valores de retorno (15 y 11) de vsnprintf("%*pbl ", ...) test:keyward es WARNING en kvasprintf WARNING: CPU: 55 PID: 1168477 en lib/kasprintf.c:30 kvasprintf+0x121/0x130 Seguimiento de llamadas: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmap_print_to_buf+0x89/0x100 core_siblings_list_read+0x7e/0xb0 kernfs_file_read_iter+0x15b/0x270 new_sync_read+0x153/0x260 vfs_read+0x215/0x290 ksys_read+0xb9/0x160 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 El seguimiento de la llamada muestra que kvasprintf() informó esta advertencia durante la impresión de core_siblings_list. kvasprintf() tiene varios pasos: (1) Primero, calcule la longitud de la cadena formateada resultante. (2) Asignar un búfer en función de la longitud devuelta. (3) Luego, realice el formateo de la cadena real. (4) Verifique si las longitudes de las cadenas formateadas devueltas en los pasos (1) y (2) son consistentes. Si se modifica core_cpumask entre los pasos (1) y (3), las longitudes obtenidas en estos dos pasos pueden no coincidir. De hecho, nuestra prueba incluye la conexión en caliente de la CPU, que debería modificar core_cpumask durante la impresión. Para solucionar este problema, almacene en caché cpumask en una variable temporal antes de llamar a cpumap_print_{list, cpumask}_to_buf(), para mantenerla sin cambios durante el proceso de impresión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: ti-ads1119: se corrige la fuga de información en el búfer activado La estructura local 'scan' se usa para enviar datos al espacio de usuario desde un búfer activado, pero tiene un agujero entre la muestra (unsigned int) y la marca de tiempo. Este agujero nunca se inicializa. Inicialice la estructura a cero antes de usarla para evitar enviar información no inicializada al espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: ti-ads8688: se corrige la fuga de información en el búfer activado La matriz local 'buffer' se utiliza para enviar datos al espacio de usuario desde un búfer activado, pero no establece valores para canales inactivos, ya que solo utiliza iio_for_each_active_channel() para asignar nuevos valores. Inicialice la matriz a cero antes de usarla para evitar enviar información no inicializada al espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: rockchip_saradc: corrige pérdida de información en búfer activado La estructura local 'data' se usa para enviar datos al espacio de usuario desde un búfer activado, pero no establece valores para canales inactivos, ya que solo usa iio_for_each_active_channel() para asignar nuevos valores. Inicialice la estructura a cero antes de usarla para evitar enviar información no inicializada al espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: imu: kmx61: se corrige la fuga de información en el búfer activado La matriz local 'buffer' se utiliza para enviar datos al espacio del usuario desde un búfer activado, pero no establece valores para canales inactivos, ya que solo utiliza iio_for_each_active_channel() para asignar nuevos valores. Inicialice la matriz a cero antes de usarla para evitar enviar información no inicializada al espacio del usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: at91: llamar a input_free_device() en iio_dev asignado La implementación actual de at91_ts_register() llama a input_free_deivce() en st->ts_input, sin embargo, se puede llegar a la etiqueta err antes de que el iio_dev asignado se almacene en st->ts_input. Por lo tanto, se llama a input_free_device() en la entrada en lugar de a st->ts_input.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ovl: soporte para codificar fid desde un inodo sin alias Dmitry Safonov informó que una aserción WARN_ON() puede ser activada por el espacio de usuario al llamar a inotify_show_fdinfo() para un inodo vigilado por overlayfs, cuyos alias dentry se descartaron con drop_caches. La aserción WARN_ON() en inotify_show_fdinfo() se eliminó, porque es posible que la codificación del identificador de archivo falle por otra razón, pero el impacto de no codificar un identificador de archivo overlayfs va más allá de esta aserción. Como se muestra en el caso de prueba LTP mencionado en el enlace a continuación, no codificar un identificador de archivo overlayfs desde un inodo sin alias también conduce a no informar un fid con eventos fanotify FAN_DELETE_SELF. Como Dmitry señala en su análisis del problema, ovl_encode_fh() falla si no puede encontrar un alias para el inodo, pero este error se puede solucionar. ovl_encode_fh() rara vez usa el alias y en el caso de identificadores de archivos no decodificables, como suele ser el caso con la información de fid de fanotify, ovl_encode_fh() nunca necesita usar el alias para codificar un identificador de archivo. Aplaza la búsqueda de un alias hasta que realmente sea necesario para que ovl_encode_fh() no falle en el caso común de eventos de fanotify FAN_DELETE_SELF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: se corrige el fallo del kernel cuando se envía 1588 en dispositivos HIP08. Actualmente, los dispositivos HIP08 no registran los dispositivos ptp, por lo que hdev->ptp es NULL. Pero el proceso tx aún intentaría establecer la información de la marca de tiempo del hardware con el indicador SKBTX_HW_TSTAMP y provocaría un fallo del kernel. [ 128.087798] No se puede gestionar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000018 ... [ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge] [ 128.292938] sp : ffff800059b93140 [ 128.297200] x29: ffff800059b93140 x28: 0000000000003280 [ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080 [ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001 [ 128.315969] x23: 0000000000000000 x22: 0000000000000194 [ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000 [ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000 [ [128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24 [128.340934] x15: 0000ffffd530a518 x14: 0000000000000000 [128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368 [128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02 [128.359606] x9: ffffcf1f85a212b4 x8: ffff0cd7cf27dab0 [ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000 [ 128.372040] x5 : 000000000000000 x4 : 000000000000ffff [ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294 [ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080 [ 128.390626] Rastreo de llamadas: [ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3] [ 128.405468] xmit_one.constprop.0+0xc4/0x200 [ 128.410600] dev_hard_start_xmit+0x54/0xf0 [ 128.415556] sch_direct_xmit+0xe8/0x634 [ 128.420246] __dev_queue_xmit+0x224/0xc70 [ 128.425101] dev_queue_xmit+0x1c/0x40 [ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch] [ 128.435409] hacer_salida+0x60/0x17c [openvswitch] [ 128.440770] hacer_ejecutar_acciones+0x898/0x8c4 [openvswitch] [ 128.446993] ovs_ejecutar_acciones+0x64/0xf0 [openvswitch] [ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch] [ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch] [ 128.465497] interno_dev_xmit+0x34/0xb0 [openvswitch] [ 128.471460] xmit_one.constprop.0+0xc4/0x200 [ 128.476561] dev_hard_start_xmit+0x54/0xf0 [ 128.481489] __dev_queue_xmit+0x968/0xc70 [ 128.486330] dev_queue_xmit+0x1c/0x40 [ 128.490856] ip_finish_output2+0x250/0x570 [ 128.495810] __ip_finish_output+0x170/0x1e0 [ 128.500832] ip_finish_output+0x3c/0xf0 [ 128.505504] ip_output+0xbc/0x160 [ 128.509654] ip_send_skb+0x58/0xd4 [ 128.513892] udp_send_skb+0x12c/0x354 [ 128.518387] udp_sendmsg+0x7a8/0x9c0 [ 128.522793] inet_sendmsg+0x4c/0x8c [ 128.527116] __sock_sendmsg+0x48/0x80 [ 128.531609] __sys_sendto+0x124/0x164 [ 128.536099] __arm64_sys_sendto+0x30/0x5c [ 128.540935] invocar_llamada_al_sistema+0x50/0x130 [ 128.545508] el0_svc_common.constprop.0+0x10c/0x124 [ 128.551205] hacer_el0_svc+0x34/0xdc [ 128.555347] el0_svc+0x20/0x30 [ 128.559227] el0_sync_handler+0xb8/0xc0 [ 128.563883] el0_sync+0x160/0x180

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net:hns3: se ha corregido el problema de que hclge_fetch_pf_reg accede al espacio de la barra fuera de los límites El espacio BAR de TQP se divide en dos segmentos. Los TQP 0-1023 y los TQP 1024-1279 están en diferentes direcciones de espacio BAR. Sin embargo, hclge_fetch_pf_reg no distingue la información del espacio tqp al leer la información del espacio tqp. Cuando el número de TQP es mayor que 1024, se produce una sobrescritura del espacio de la barra de acceso. El problema de los diferentes segmentos se ha considerado durante la inicialización de tqp.io_base. Por lo tanto, tqp.io_base se utiliza directamente cuando se lee la cola en hclge_fetch_pf_reg. Mensaje de error: No se puede gestionar la solicitud de paginación del núcleo en la dirección virtual ffff800037200000 pc : hclge_fetch_pf_reg+0x138/0x250 [hclge] lr : hclge_get_regs+0x84/0x1d0 [hclge] Call trace: hclge_fetch_pf_reg+0x138/0x250 [hclge] hclge_get_regs+0x84/0x1d0 [hclge] hns3_get_regs+0x2c/0x50 [hns3] ethtool_get_regs+0xf4/0x270 dev_ethtool+0x674/0x8a0 dev_ioctl+0x270/0x36c sock_do_ioctl+0x110/0x2a0 sock_ioctl+0x2ac/0x530 __arm64_sys_ioctl+0xa8/0x100 invoke_syscall+0x4c/0x124 el0_svc_common.constprop.0+0x140/0x15c do_el0_svc+0x30/0xd0 el0_svc+0x1c/0x2c el0_sync_handler+0xb0/0xb4 el0_sync+0x168/0x180

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: no habilitar automáticamente misc vector Actualmente, hay una ventana de tiempo entre la habilitación de misc irq y la iniciación de la tarea de servicio. Si se informa una interrupción en este momento, se generará una advertencia como la siguiente: [ 16.324639] Rastreo de llamadas: [ 16.324641] __queue_delayed_work+0xb8/0xe0 [ 16.324643] mod_delayed_work_on+0x78/0xd0 [ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge] [ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge] [ 16.324666] __handle_irq_event_percpu+0x64/0x1e0 [ 16.324667] handle_irq_event+0x80/0x170 [ 16.324670] gestionar_fasteoi_edge_irq+0x110/0x2bc [ 16.324671] __gestionar_dominio_irq+0x84/0xfc [ 16.324673] gic_gestionar_irq+0x88/0x2c0 [ 16.324674] el1_irq+0xb8/0x140 [ 16.324677] arch_cpu_idle+0x18/0x40 [ 16.324679] llamada_inactiva_por_defecto+0x5c/0x1bc [ 16.324682] llamada_inactiva_cpu_idle+0x18c/0x1c4 [ 16.324684] do_idle+0x174/0x17c [ 16.324685] cpu_startup_entry+0x30/0x6c [ 16.324687] secondary_start_kernel+0x1a4/0x280 [ 16.324688] ---[ fin de seguimiento 6aa0bff672a964aa ]--- Por lo tanto, no habilite automáticamente el vector misceláneo cuando solicite irq.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipvlan: Se ha corregido el error use-after-free en ipvlan_get_iflink(). syzbot presentó un informe de error use-after-free [0] sobre ipvlan y linkwatch. ipvlan no contiene un refcnt del dispositivo inferior a diferencia de vlan y macvlan. Si se activa el trabajo de linkwatch para el dispositivo ipvlan dev, es posible que el dispositivo inferior ya se haya liberado, lo que da como resultado un UAF de ipvlan->phy_dev en ipvlan_get_iflink(). Podemos retrasar la anulación del registro del dispositivo inferior como vlan y macvlan al retener el refcnt del dispositivo inferior en dev->netdev_ops->ndo_init() y liberarlo en dev->priv_destructor(). Jakub señaló que llamar a .ndo_XXX después de que unregister_netdevice() haya regresado es propenso a errores y sugirió [1] abordar este UAF en el núcleo llevando más allá el commit 750e51603395 ("net: evitar un UAF potencial en default_operstate()"). Supongamos que se cancela el registro de dispositivos y usemos la protección RCU en default_operstate() para no competir con la cancelación del registro del dispositivo. [0]: ERROR: KASAN: slab-use-after-free in ipvlan_get_iflink+0x84/0x88 drivers/net/ipvlan/ipvlan_main.c:353 Read of size 4 at addr ffff0000d768c0e0 by task kworker/u8:35/6944 CPU: 0 UID: 0 PID: 6944 Comm: kworker/u8:35 Not tainted 6.13.0-rc2-g9bc5c9515b48 #12 4c3cb9e8b4565456f6a355f312ff91f4f29b3c47 Hardware name: linux,dummy-virt (DT) Workqueue: events_unbound linkwatch_event Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:484 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load4_noabort+0x20/0x30 mm/kasan/report_generic.c:380 ipvlan_get_iflink+0x84/0x88 drivers/net/ipvlan/ipvlan_main.c:353 dev_get_iflink+0x7c/0xd8 net/core/dev.c:674 default_operstate net/core/link_watch.c:45 [inline] rfc2863_policy+0x144/0x360 net/core/link_watch.c:72 linkwatch_do_dev+0x60/0x228 net/core/link_watch.c:175 __linkwatch_run_queue+0x2f4/0x5b8 net/core/link_watch.c:239 linkwatch_event+0x64/0xa8 net/core/link_watch.c:282 process_one_work+0x700/0x1398 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x8c4/0xe10 kernel/workqueue.c:3391 kthread+0x2b0/0x360 kernel/kthread.c:389 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:862 Allocated by task 9303: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4283 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4289 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:650 alloc_netdev_mqs+0xb4/0x1118 net/core/dev.c:11209 rtnl_create_link+0x2b8/0xb60 net/core/rtnetlink.c:3595 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3771 __rtnl_newlink net/core/rtnetlink.c:3896 [inline] rtnl_newlink+0x122c/0x15c0 net/core/rtnetlink.c:4011 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6901 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2542 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6928 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg net/socket.c:726 [inline] __sys_sendto+0x2ec/0x438 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __arm64_sys_sendto+0xe4/0x110 net/socket.c:2200 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x---truncado---