Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btrtl: Prevenir posible desreferencia de NULL. La función btrtl_initialize() comprueba si rtl_load_file() tuvo un error o cargó un archivo de longitud cero. Sin embargo, si cargó un archivo de longitud cero, el código de error no se configura correctamente. Esto genera un error de puntero de error vs. NULL, seguido de una desreferencia de puntero NULL. Esto fue detectado por Smatch: drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxgb4: Se corrige la fuga de memoria en la ruta de error de cxgb4_init_ethtool_filters(). En el bucle for utilizado para asignar loc_array y bmap para cada puerto, es posible que se produzca una fuga de memoria cuando la asignación de loc_array se realiza correctamente, pero la de bmap falla. Esto se debe a que, cuando el flujo de control accede a la etiqueta free_eth_finfo, solo se liberan las asignaciones a partir de la iteración (i-1). Para solucionar esto, libere loc_array en la ruta de error de asignación de bmap.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: openvswitch: corrección de la validación de la longitud de la clave anidada en la acción set(). No es seguro acceder a nla_len(ovs_key) si los datos son menores que el encabezado netlink. Compruebe primero que el atributo esté correcto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mctp: La búsqueda de enlace Set SOCK_RCU_FREE se ejecuta bajo RCU, por lo que debe asegurarse de que un socket no desaparezca en medio de una búsqueda.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: mv88e6xxx: evitar anular el registro de regiones devlink que nunca se registraron Russell King informa que un sistema con mv88e6xxx desreferencia un puntero NULL al desvincular este controlador: https://lore.kernel.org/netdev/Z_lRkMlTJ1KQ0kVX@shell.armlinux.org.uk/ El fallo parece estar en devlink_region_destroy(), que no tolera NULL pero se le asigna un puntero de región global devlink NULL. Al menos en algunos chips, algunas regiones devlink se registran condicionalmente desde la confirmación culpable, consulte mv88e6xxx_setup_devlink_regions_global(): if (cond && !cond(chip)) continue; Estos son MV88E6XXX_REGION_STU y MV88E6XXX_REGION_PVT. Si el chip no tiene una STU o PVT, debería fallar de esta manera. Para solucionar el problema, evite anular el registro de las regiones nulas, es decir, las que se omitieron al ejecutar mv88e6xxx_setup_devlink_regions_global().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: Purgar la txq de vif en ieee80211_do_stop(). Después de ieee80211_do_stop(), el SKB de la txq de vif aún podía procesarse. De hecho, otra llamada simultánea a vif schedule_and_wake_txq podría provocar que esos paquetes se descolgaran (véase ieee80211_handle_wake_tx_queue()) sin comprobar el estado actual de sdata. Dado que vif.drv_priv se borra en esta función, esto podría provocar un fallo del controlador. Por ejemplo, en ath12k, ahvif se almacena en vif.drv_priv. Por lo tanto, si se llama ath12k_mac_op_tx() después de ieee80211_do_stop(), ahvif->ah puede ser NULL, lo que lleva a la llamada ath12k_warn(ahvif->ah,...) en esta función a activar la deref NULL a continuación. No se puede gestionar la solicitud de paginación del núcleo en la dirección virtual dfffffc000000001 KASAN: null-ptr-deref en el rango [0x000000000000008-0x000000000000000f] batman_adv: bat0: Interfaz desactivada: brbh1337 Información de aborto de memoria: ESR = 0x0000000096000004 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: fallo de traducción de nivel 0 Información de aborto de datos: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] dirección entre rangos de direcciones de usuario y kernel Error interno: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd No contaminado 6.13.0-g633f875b8f1e #114 Nombre del hardware: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 000000000000000 x12: ffffffb003a0bf03 x11: 000000000000000 x10: ffffffb003a0bf02 x9: ffffff8034a19f40 x8: ffffff801d05f818 x7: 1ffffff0069433dc x6: ffffff8034a19ee0 x5: ffffff801d05f7f0 x4: 0000000000000000 x3: 0000000000000001 x2: 0000000000000000 x1: dfffffc000000000 x0: 0000000000000008 Rastreo de llamadas: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158 Para evitar eso, vacíe el txq de vif en ieee80211_do_stop() para que ningún paquete pueda sacarse de la cola después de ieee80211_do_stop() (los paquetes nuevos no pueden ponerse en cola porque SDATA_STATE_RUNNING se borra en este punto).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ethtool: cmis_cdb: use el tamaño rpl correcto en ethtool_cmis_module_poll() rpl se pasa como un puntero a ethtool_cmis_module_poll(), por lo que el tamaño correcto de rpl es sizeof(*rpl), que debería ser solo 1 byte. El uso del tamaño del puntero en su lugar puede causar corrupción en la pila: Pánico del kernel - no sincroniza: protector de pila: La pila del kernel está dañada en: ethtool_cmis_wait_for_cond+0xf4/0x100 CPU: 72 UID: 0 PID: 4440 Comm: kworker/72:2 Kdump: cargado Contaminado: G OE 6.11.0 #24 Contaminado: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Nombre del hardware: Dell Inc. PowerEdge R760/04GWWM, BIOS 1.6.6 20/09/2023 Cola de trabajo: eventos module_flash_fw_work Rastreo de llamadas: panic+0x339/0x360 ? ethtool_cmis_wait_for_cond+0xf4/0x100 ? __pfx_status_success+0x10/0x10 ? __pfx_status_fail+0x10/0x10 __stack_chk_fail+0x10/0x10 ethtool_cmis_wait_for_cond+0xf4/0x100 ethtool_cmis_cdb_execute_cmd+0x1fc/0x330 ? __pfx_status_fail+0x10/0x10 cmis_cdb_module_features_get+0x6d/0xd0 ethtool_cmis_cdb_init+0x8a/0xd0 ethtool_cmis_fw_update+0x46/0x1d0 module_flash_fw_work+0x17/0xa0 process_one_work+0x179/0x390 worker_thread+0x239/0x340 ? __pfx_worker_thread+0x10/0x10 kthread+0xcc/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hfs/hfsplus: se corrige slab-out-of-bounds en hfs_bnode_read_key Syzbot informó de un problema en el subsistema hfs: ERROR: KASAN: slab-out-of-bounds en memcpy_from_page include/linux/highmem.h:423 [en línea] ERROR: KASAN: slab-out-of-bounds en hfs_bnode_read fs/hfs/bnode.c:35 [en línea] ERROR: KASAN: slab-out-of-bounds en hfs_bnode_read_key+0x314/0x450 fs/hfs/bnode.c:70 Escritura de tamaño 94 en la dirección ffff8880123cd100 por la tarea syz-executor237/5102 Rastreo de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [en línea] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 memcpy_from_page include/linux/highmem.h:423 [en línea] hfs_bnode_read fs/hfs/bnode.c:35 [en línea] hfs_bnode_read_key+0x314/0x450 fs/hfs/bnode.c:70 hfs_brec_insert+0x7f3/0xbd0 fs/hfs/brec.c:159 hfs_cat_create+0x41d/0xa50 fs/hfs/catalog.c:118 hfs_mkdir+0x6c/0xe0 fs/hfs/dir.c:232 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdir fs/namei.c:4300 [en línea] __se_sys_mkdir fs/namei.c:4298 [en línea] __x64_sys_mkdir+0x6c/0x80 fs/namei.c:4298 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fbdd6057a99 Se ha añadido una comprobación de la longitud de la clave en hfs_bnode_read_key para evitar el acceso a memoria fuera de los límites. Si la longitud de la clave no es válida, se borra el búfer de claves, lo que mejora la estabilidad y la fiabilidad.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ti: icss-iep: Se corrige una posible desreferencia de puntero nulo para la solicitud perout. El controlador IEP de ICSS rastrea el estado de habilitación de perout y pps mediante indicadores. Actualmente, al deshabilitar las señales pps y perout durante icss_iep_exit(), se produce una desreferencia de puntero nulo para perout. Para solucionar el problema de desreferencia de puntero nulo, se puede modificar la función icss_iep_perout_enable_hw para borrar directamente los registros CMP de IEP al deshabilitar PPS o PEROUT, sin referenciar la estructura ptp_perout_request, ya que su contenido es irrelevante en este caso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: cros-ec-tunnel: aplazar la sonda si el EC principal no está presente. Cuando i2c-cros-ec-tunnel y el controlador EC están integrados, no se encuentra el dispositivo principal EC, lo que provoca una desreferencia de puntero nulo. Esto también se puede reproducir desvinculando el controlador y cargando el módulo i2c-cros-ec-tunnel (o vinculando el dispositivo). [ 271.991245] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000058 [ 271.998215] #PF: acceso de lectura del supervisor en modo núcleo [ 272.003351] #PF: error_code(0x0000) - página no presente [ 272.008485] PGD 0 P4D 0 [ 272.011022] Oops: Oops: 0000 [#1] SMP NOPTI [ 272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S 6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full) 3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5 [ 272.030312] Tainted: [S]=CPU_OUT_OF_SPEC [ 272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021 [ 272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel] [ 272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 <49> 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9 [ 272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282 [ 272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000 [ 272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00 [ 272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000 [ 272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000 [ 272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10 [ 272.108198] FS: 00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000 [ 272.116282] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0 [ 272.129155] Call Trace: [ 272.131606] [ 272.133709] ? acpi_dev_pm_attach+0xdd/0x110 [ 272.137985] platform_probe+0x69/0xa0 [ 272.141652] really_probe+0x152/0x310 [ 272.145318] __driver_probe_device+0x77/0x110 [ 272.149678] driver_probe_device+0x1e/0x190 [ 272.153864] __driver_attach+0x10b/0x1e0 [ 272.157790] ? driver_attach+0x20/0x20 [ 272.161542] bus_for_each_dev+0x107/0x150 [ 272.165553] bus_add_driver+0x15d/0x270 [ 272.169392] driver_register+0x65/0x110 [ 272.173232] ? cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698] [ 272.182617] do_one_initcall+0x110/0x350 [ 272.186543] ? security_kernfs_init_security+0x49/0xd0 [ 272.191682] ? __kernfs_new_node+0x1b9/0x240 [ 272.195954] ? security_kernfs_init_security+0x49/0xd0 [ 272.201093] ? __kernfs_new_node+0x1b9/0x240 [ 272.205365] ? kernfs_link_sibling+0x105/0x130 [ 272.209810] ? kernfs_next_descendant_post+0x1c/0xa0 [ 272.214773] ? kernfs_activate+0x57/0x70 [ 272.218699] ? kernfs_add_one+0x118/0x160 [ 272.222710] ? __kernfs_create_file+0x71/0xa0 [ 272.227069] ? sysfs_add_bin_file_mode_ns+0xd6/0x110 [ 272.232033] ? internal_create_group+0x453/0x4a0 [ 272.236651] ? __vunmap_range_noflush+0x214/0x2d0 [ 272.241355] ? __free_frozen_pages+0x1dc/0x420 [ 272.245799] ? free_vmap_area_noflush+0x10a/0x1c0 [ 272.250505] ? load_module+0x1509/0x16f0 [ 272.254431] do_init_module+0x60/0x230 [ 272.258181] __se_sys_finit_module+0x27a/0x370 [ 272.262627] do_syscall_64+0x6a/0xf0 [ 272.266206] ? do_syscall_64+0x76/0xf0 [ 272.269956] ? irqentry_exit_to_user_mode+0x79/0x90 [ 272.274836] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 272.279887] RIP: 0033:0x7b9309168d39 [ 272.283466] Code: 5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d af 40 0c 00 f7 d8 64 89 01 8 [ 272.302210] RSP: 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/dpu: Corrección de punteros de error en dpu_plane_virtual_atomic_check. La función dpu_plane_virtual_atomic_check desreferenciaba los punteros devueltos por drm_atomic_get_plane_state sin comprobar si había errores. Esto podría provocar un comportamiento indefinido si la función devuelve un puntero de error. Esta confirmación añade comprobaciones mediante IS_ERR para garantizar que plane_state sea válido antes de desreferenciarlo. Similar al commit da29abe71e16 ("drm/amd/display: Corrección de punteros de error en amdgpu_dm_crtc_mem_type_changed"). Patchwork: https://patchwork.freedesktop.org/patch/643132/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: tabla de enrutamiento libre en caso de fallo de sondeo. Si "complete" es verdadero en dsa_tree_setup(), significa que somos el último conmutador del árbol que está sondeando correctamente, y deberíamos estar configurando todos los conmutadores desde nuestra ruta de sondeo. Una vez que "complete" es verdadero, dsa_tree_setup_cpu_ports() o cualquier función posterior puede fallar. Si esto ocurre, toda la configuración del árbol queda en el limbo: los primeros N-1 conmutadores han finalizado el sondeo correctamente (sin hacer nada más que asignar memoria persistente en dst->ports del árbol, y quizás en dst->rtable), y el conmutador N no ha podido sondear, finalizando el proceso de configuración del árbol antes de que el usuario pueda ver nada tangible. Si el conmutador N no puede sondear, su memoria (puertos) se liberará y se eliminará de dst->ports. Sin embargo, los elementos dst->rtable que apuntan a sus puertos, tal como los creó dsa_link_touch(), permanecerán allí y darán lugar a un use-after-free si se desreferencian. Si dsa_tree_setup_switches() devuelve -EPROBE_DEFER, lo cual es completamente posible porque es donde está ds->ops->setup(), obtenemos un informe de kasan como este: ===================================================================== ERROR: KASAN: slab-use-after-free en mv88e6xxx_setup_upstream_port+0x240/0x568 Lectura de tamaño 8 en la dirección ffff000004f56020 por la tarea kworker/u8:3/42 Rastreo de llamadas: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350 La forma más sencilla de corregir el error es eliminar la tabla de enrutamiento en su totalidad. dsa_tree_setup_routing_table() no tiene problemas para regenerarla incluso si eliminamos enlaces entre puertos distintos a los del switch N, ya que dsa_link_touch() primero comprueba si el par de puertos ya existe en dst->rtable, y la asigna en caso contrario. La eliminación completa de la tabla de enrutamiento ya existe en dsa_tree_teardown(), por lo que se debe refactorizar en una función que también pueda llamarse desde la ruta de error de configuración del árbol. En mi análisis de la confirmación responsable, es la que añadió elementos dsa_link a dst->rtable. Antes de eso, cada switch tenía su propia ds->rtable, que se libera cuando el switch falla al sondear. Sin embargo, el árbol es potencialmente memoria persistente.