Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: evita la desreferencia a NULL en ip6_output() Según syzbot, existe la posibilidad de que ip6_dst_idev() devuelva NULL en ip6_output(). La mayoría de los lugares en la pila IPv6 manejan un idev NULL muy bien, pero no aquí. syzbot informó: falla de protección general, probablemente para dirección no canónica 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en rango [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: ejecutor. 4 No contaminado 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output. c:237 Código: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 00000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: ffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: NF_HOOK include/linux/netfilter.h:314 [en línea] ip6_xmit+0xefe /0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net /sctp/cola de salida. c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [en línea] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [en línea] 9cc/0x60c0 neto/ sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [en línea] sctp_inet_connect+ 0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [en línea] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [en línea] __se_sys_connect red/socket .c:2072 [en línea] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entrada_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: fib6_rules: evita una posible desreferencia NULL en fib6_rule_action() syzbot es capaz de desencadenar el siguiente bloqueo [1], causado por el uso inseguro de ip6_dst_idev(). De hecho, ip6_dst_idev() puede devolver NULL y siempre debe verificarse. [1] Vaya: fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm : syz- executor.0 No contaminado 6.9.0-rc4-next-20240417-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c: 237 [en línea] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267 Código: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP:ffffc9000fc1f2f 0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673f b980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: ffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff88807650 9000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS :ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000400 Seguimiento de llamadas: fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [en línea] gs+0x38e/0x610 neto /ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [en línea] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst +0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/ 0x6c0 neto/sctp/ socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [en línea] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket .c:2048 [en línea] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [en línea] __se_sys_connect net/socket.c:2072 [en línea] __x64_sys_connect+0x7a/0x90 net/socket. c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpiolib: cdev: corrige el use after free en lineinfo_changed_notify El problema de use after free ocurre de la siguiente manera: cuando el archivo del dispositivo del chip GPIO se cierra al invocar gpio_chrdev_release(), las líneas vigiladas son liberado por bitmap_free(), pero la cancelación del registro de la cadena de notificador lineinfo_changed_nb falló debido a la espera de escritura de rwsem. Además, una de las líneas del chip GPIO también está en proceso de lanzamiento y contiene el rwsem de lectura de la cadena notificadora. En consecuencia, una condición de ejecución conduce al use after free de watched_lines. Aquí está la pila típica cuando ocurrió el problema: [free] gpio_chrdev_release() --> bitmap_free(cdev->watched_lines) <-- freed --> blocking_notifier_chain_unregister() --> down_write(&nh->rwsem) <-- waiting rwsem --> __down_write_common() --> rwsem_down_write_slowpath() --> schedule_preempt_disabled() --> schedule() [use] st54spi_gpio_dev_release() --> gpio_free() --> gpiod_free() --> gpiod_free_commit() --> gpiod_line_state_notify() --> blocking_notifier_call_chain() --> down_read(&nh->rwsem); <-- held rwsem --> notifier_call_chain() --> lineinfo_changed_notify() --> test_bit(xxxx, cdev->watched_lines) <-- use after free El efecto secundario del problema de use after free es que un GPIO El evento de línea se está generando para el espacio de usuario donde no debería. Sin embargo, dado que chrdev se cerrará, el espacio de usuario no tendrá la oportunidad de leer ese evento de todos modos. Para solucionar el problema, llame a la función bitmap_free() después de cancelar el registro de la cadena de notificadores lineinfo_changed_nb.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: corrige el posible acceso a valores uninit en __ip6_make_skb() Como se hizo en el commit fc1092f51567 ("ipv4: corrige el acceso a valores uninit en __ip_make_skb()") para IPv4, verifique FLOWI_FLAG_KNOWN_NH en fl6->flowi6_flags en lugar de probar HDRINCL en el socket para evitar una condición de ejecución que provoque acceso a valores uninit.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: tcp: utilice refcount_inc_not_zero() en tcp_twsk_unique(). Anderson Nascimento informó sobre un símbolo de use after free en tcp_twsk_unique() con un buen análisis. Desde el commit ec94c2696f0b ("tcp/dccp: evitar una operación atómica para timewait hashdance"), inet_twsk_hashdance() establece el sk_refcnt del socket TIME-WAIT después de ponerlo en ehash y liberar el bloqueo del depósito. Por lo tanto, hay una pequeña ventana de ejecución donde otros subprocesos podrían intentar reutilizar el puerto durante connect() y llamar a sock_hold() en tcp_twsk_unique() para el socket TIME-WAIT con cero refcnt. Si eso sucede, el refcnt tomado por tcp_twsk_unique() se sobrescribe y sock_put() provocará un desbordamiento insuficiente, lo que desencadenará un use after free real en otro lugar. Para evitar el use after free, debemos usar refcount_inc_not_zero() en tcp_twsk_unique() y renunciar a reutilizar el puerto si devuelve falso. [0]: refcount_t: suma en 0; use after free. ADVERTENCIA: CPU: 0 PID: 1039313 en lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: disparador No contaminado 6.8.6-200.fc39.x86_64 #1 Nombre de hardware: VMware, Inc. Plataforma de referencia de escritorio VMware20,1/440BX, BIOS VMW201.00V.21805430.B64.2305221830 22/05/2023 RIP: 0010:refcount_warn_saturate+0xe5/0x110 Código: 42 8e ff 0f 0b c3 cc cc cc 80 3d aa 13 cada uno 01 00 0f 85 5e ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 0 1 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 00000000000000027 RDX: ffff88807be218c8 RSI: 00000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 000000000000 0003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Seguimiento de llamadas: ? refcount_warn_saturate+0xe5/0x110? __advertir+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110? report_bug+0x171/0x1a0? refcount_warn_saturate+0xe5/0x110? handle_bug+0x3c/0x80? exc_invalid_op+0x17/0x70? asm_exc_invalid_op+0x1a/0x20? refcount_warn_saturate+0xe5/0x110 tcp_twsk_unique+0x186/0x190 __inet_check_establecido+0x176/0x2d0 __inet_hash_connect+0x74/0x7d0 ? __pfx___inet_check_establecido+0x10/0x10 tcp_v4_connect+0x278/0x530 __inet_stream_connect+0x10f/0x3d0 inet_stream_connect+0x3a/0x60 __sys_connect+0xa8/0xd0 __x64_sys_connect+0x18/0x20 _64+0x83/0x170 entrada_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Código: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 73 01 c3 48 8b 0d a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 0000000000000002a RAX: ffffffffffffffda RBX: 20ccb004 RCX: 00007f62c11a885d RDX: 00000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000 0000R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 07ffe237885b0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slab: make __free(kfree) acepta punteros de error Actualmente, si una asignación liberada automáticamente es un puntero de error que provocará un bloqueo. Un ejemplo de esto está en wm831x_gpio_dbg_show(). 171 caracteres *etiqueta __free(kfree) = gpiochip_dup_line_label(chip, i); 172 if (IS_ERR(etiqueta)) { 173 dev_err(wm831x->dev, "Error al duplicar la etiqueta\n"); 174 continúan; 175 } La función de limpieza automática también debería comprobar si hay indicadores de error; de lo contrario, seguiremos teniendo problemas como este.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/nouveau/firmware: corrija el error SG_DEBUG con nvkm_firmware_ctor() Actualmente, habilitar SG_DEBUG en el kernel hará que nouveau alcance un ERROR() al inicio: kernel ERROR en include/linux /scatterlist.h:187! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 PID: 930 Comm: (udev-worker) No contaminado 6.9.0-rc3Lyude-Test+ #30 Nombre del hardware: MSI MS-7A39/A320M GAMING PRO (MS-7A39 ), BIOS 1.I0 22/01/2019 RIP: 0010:sg_init_one+0x85/0xa0 Código: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54 24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b 0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00 RSP: bf6a0 EFLAGS: 00010246 RAX: 0000000000000000 RBX : ffffa77600d87000 RCX: 000000000000002b RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000 RBP: 00000000000e000 R08: 00000000000 R09: 0000000000000000 R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508 R13: ffff98f4c46aa008 R14: ffffa77600d4 a000 R15: ffffa77600d4a018 FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000 (0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 0000000000350 6f0 Seguimiento de llamadas: ? morir+0x36/0x90? do_trap+0xdd/0x100? sg_init_one+0x85/0xa0? do_error_trap+0x65/0x80? sg_init_one+0x85/0xa0? exc_invalid_op+0x50/0x70? sg_init_one+0x85/0xa0? asm_exc_invalid_op+0x1a/0x20? [ nuevo] ? srso_return_thunk+0x5/0x5f? srso_return_thunk+0x5/0x5f? nvkm_udevice_new+0x95/0x140 [nuevo] ? srso_return_thunk+0x5/0x5f? srso_return_thunk+0x5/0x5f? ktime_get+0x47/0xb0? srso_return_thunk+0x5/0x5f nvkm_subdev_oneinit_+0x4f/0x120 [nuevo] nvkm_subdev_init_+0x39/0x140 [nuevo] ? srso_return_thunk+0x5/0x5f nvkm_subdev_init+0x44/0x90 [nuevo] nvkm_device_init+0x166/0x2e0 [nuevo] nvkm_udevice_init+0x47/0x70 [nuevo] nvkm_object_init+0x41/0x1c0 nvkm_ioctl_new+0x16a/0x290 [nuevo] ? __pfx_nvkm_client_child_new+0x10/0x10 [nuevo] ? __pfx_nvkm_udevice_new+0x10/0x10 [nuevo] nvkm_ioctl+0x126/0x290 [nuevo] nvif_object_ctor+0x112/0x190 [nuevo] nvif_device_ctor+0x23/0x60 [nuevo] 0 [nuevo] nouveau_drm_device_init+0x97/0x9e0 [nuevo] ? srso_return_thunk+0x5/0x5f? pci_update_current_state+0x72/0xb0? srso_return_thunk+0x5/0x5f nouveau_drm_probe+0x12c/0x280 [nuevo] ? srso_return_thunk+0x5/0x5f local_pci_probe+0x45/0xa0 pci_device_probe+0xc7/0x270 very_probe+0xe6/0x3a0 __driver_probe_device+0x87/0x160 driver_probe_device+0x1f/0xc0 __driver_attach+0xec/0x1f 0 ? __pfx___driver_attach+0x10/0x10 bus_for_each_dev+0x88/0xd0 bus_add_driver+0x116/0x220 driver_register+0x59/0x100 ? __pfx_nouveau_drm_init+0x10/0x10 [nuevo] do_one_initcall+0x5b/0x320 do_init_module+0x60/0x250 init_module_from_file+0x86/0xc0 idempotent_init_module+0x120/0x2b0 __x64_sys_finit_module+0 x5e/0xb0 do_syscall_64+0x83/0x160? srso_return_thunk+0x5/0x5f Entry_SYSCALL_64_after_hwframe+0x71/0x79 RIP: 0033:0x7feeb5cc20cd Código: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 9 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 1b cd 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffcf220b2c8 EFLAGS: ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000055fdd2916aa0 RCX: 00007feeb5cc20cd RDX: 0000000000000000 RSI: 000055fdd29161e0 RDI: 0000000000000035 RBP: 00007ffcf220b380 R08: 00007feeb5d8fb20 R09: ffcf220b310 R10: 000055fdd2909dc0 R11: 0000000000000246 R12: 000055 ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: e1000e: cambie usleep_range a udelay en el acceso mdic de PHY. Esta es una reversión parcial de el commit 6dbdd4de0362 ("e1000e: solución alternativa para errores MDI esporádicos en sistemas Meteor Lake"). El commit a la que se hace referencia usó usleep_range dentro de las rutinas de acceso PHY, que a veces se llaman desde un contexto atómico. Esto puede provocar un pánico en el kernel en algunos escenarios, como la desconexión y reconexión de cables en sistemas vPro. Resuelva esto volviendo a cambiar las llamadas usleep_range a udelay.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: workqueue: Se corrigió la selección de wake_cpu en kick_pool() Con cpu_possible_mask=0-63 y cpu_online_mask=0-7 se observaron los siguientes errores del kernel: smp: Apareciendo CPU secundarias... smp: abrió 1 nodo, 8 CPU No se puede manejar la desreferencia del puntero del kernel en el espacio de direcciones virtual del kernel Dirección fallida: 0000000000000000 TEID: 0000000000000803 [..] Seguimiento de llamadas: arch_vcpu_is_preempted+0x12/0x80 select_idle_sibling+0x42/0x560 _rq_fair+0x29a/0x3b0 intenta_despertar_up +0x38e/0x6e0 kick_pool+0xa4/0x198 __queue_work.part.0+0x2bc/0x3a8 call_timer_fn+0x36/0x160 __run_timers+0x1e2/0x328 __run_timer_base+0x5a/0x88 run_timer_softirq+0x40/0x78 irq+0x118/0x388 irq_exit_rcu+0xc0/0xd8 hacer_ext_irq+ 0xae/0x168 ext_int_handler+0xbe/0xf0 psw_idle_exit+0x0/0xc default_idle_call+0x3c/0x110 do_idle+0xd4/0x158 cpu_startup_entry+0x40/0x48 rest_init+0xc6/0xc8 startup_continue+0x3c/0x50 El bloqueo se produce al llamar a arch_vcpu_is_preempted () para una CPU fuera de línea. Para evitar esto, seleccione la CPU con cpumask_any_and_distribute() para enmascarar __pod_cpumask con cpu_online_mask. En caso de que no quede ninguna CPU en el grupo, omita la tarea. tj: Esto no soluciona completamente el error ya que las CPU aún pueden fallar entre la selección de la CPU de destino y la llamada de activación. Para solucionarlo, es probable que sea necesario agregar la prueba cpu_online() al código arch sched o s390. Sin embargo, independientemente de cómo se solucione, workqueue no debería elegir una CPU que no esté en línea, ya que eso resultaría en un comportamiento peor e impredecible.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: maple_tree: corrige la desreferencia del puntero nulo mas_empty_area_rev() Actualmente el código llama a mas_start() seguido de mas_data_end() si el estado del arce es MA_START, pero mas_start() puede regresar con el estado del arce nodo == NULL. Esto dará lugar a una desreferencia del puntero nulo al verificar la información en el nodo NULL, lo cual se realiza en mas_data_end(). Evite establecer el desplazamiento si no hay ningún nodo esperando hasta que se verifique el estado del arce para detectar un estado vacío o de entrada única. Un usuario podría desencadenar los eventos para causar un kernel ups al desasignar todos los vmas para producir un árbol de arce vacío y luego mapear un vma que causaría el escenario descrito anteriormente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slub: evita poner a cero el puntero libre de objetos externos para un solo commit libre 284f17ac13fe ("mm/slub: maneja la liberación masiva y de objetos individuales por separado") divide la liberación de objetos únicos y masivos en dos funciones slab_free() y slab_free_bulk() lo que lleva a slab_free() a llamar a slab_free_hook() directamente en lugar de slab_free_freelist_hook(). Si se establece `init_on_free`, slab_free_hook() pone a cero el objeto. Luego, si se configuran `slub_debug=F` y `CONFIG_SLAB_FREELIST_HARDENED`, la ruta lenta do_slab_free() ejecuta comprobaciones de coherencia de la lista libre e intenta decodificar un freepointer puesto a cero, lo que conduce a una detección de "Freepointer corrupto" en check_object(). Durante la liberación masiva, slab_free_freelist_hook() no se ve afectado ya que siempre establece el puntero libre de sus objetos usando set_freepointer() para mantener su lista libre reconstruida después de `init_on_free`. Para un solo libre, el puntero libre del objeto debe evitarse cuando se almacena fuera del objeto si está configurado "init_on_free". El puntero libre se deja como está, check_object() puede detectar más adelante un valor de puntero no válido debido a un desbordamiento de objetos. Para reproducir, configure `slub_debug=FU init_on_free=1 log_level=7` en la línea de comando de una compilación del kernel con `CONFIG_SLAB_FREELIST_HARDENED=y`. Registro de muestra de dmesg: [10.708715] ============================================ ================================== [10.710323] ERROR kmalloc-rnd-05-32 (Contaminado: GBT) : Freepointer corrupto [10.712695] -------------------------------------------- --------------------------------- [ 10.712695] [ 10.712695] Losa 0xffffd8bdc400d580 objetos=32 usados=4 fp=0xffff9d9a80356f80 flags=0x200000000000a00(workingset|slab|node=0|zone=2) [ 10.716698] Objeto 0xffff9d9a80356600 @offset=1536 fp=0x7ee4f480ce0ecd7c [ 10.716698] [ 10.716698] Bytes b4 9d9a803565f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.720703] Objeto ffff9d9a80356600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ [ 10.720703] Objeto ffff9d9a80356610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.724696] Relleno ffff9d9a8035666c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.724696] Relleno ffff9d9a8035667c: 00 00 00 00 .... [ 10.724696 ] FIX kmalloc-rnd-05-32: Objeto en 0xffff9d9a80356600 no liberado

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tcpm: verifique la validez del socio del puerto antes de consumirlo. typec_register_partner() no garantiza que el registro del socio sea siempre exitoso. En caso de error, puerto->socio se establece en el valor de error o NULL. Dado que no se verifica la validez del puerto->partner, esto produce el siguiente bloqueo: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual xx pc: run_state_machine+0x1bc8/0x1c08 lr: run_state_machine+0x1b90/0x1c08 .. Seguimiento de llamadas: run_state_machine+ 0x1bc8/0x1c08 tcpm_state_machine_work+0x94/0xe4 kthread_worker_fn+0x118/0x328 kthread+0x1d0/0x23c ret_from_fork+0x10/0x20 Para evitar el bloqueo, verifique la validez del puerto->partner antes de eliminar la barrera en todos los sitios de llamadas.