Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: io_uring/sqpoll: solución alternativa a una posible pérdida de memoria de auditoría. kmemleak se queja de que hay una pérdida de memoria relacionada con el manejo de la conexión: objeto sin referencia 0xffff0001093bdf00 (tamaño 128): comm "iou-sqp-455 ", pid 457, jiffies 4294894164 volcado hexadecimal (primeros 32 bytes): 02 00 fa ea 7f 00 00 01 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso (crc 2e481b1a): [<00000000c0a26af4>] kmemleak_alloc+0x30/0x38 [<000000009c30bb45>] kmalloc_trace+0x228/0x358 [<000000009da9d39f>] __audit_sockaddr+0xd0/0x138 [<0000000089a93e34>] move_addr_to_kernel+0x1a0/0x1f8 [<000000000b4e80e6>] connect_prep+0x1ec/0x2d4 [<00000000abfbcd99>] io_submit_sqes+0x588/0x1e48 [<00000000e7c25e07>] io_sq_thread+0x8a4/0x10e4 [<00000000d999b491>] ret_from_fork+0x10/0x20 lo que puede suceder si: 1) El tipo de comando hace algo en el lado de preparación que desencadena una llamada de auditoría. 2) El hilo no ha realizado ninguna operación antes de esto que haya desencadenado una llamada de auditoría dentro de ->issue(), donde tenemos audit_uring_entry() y audit_uring_exit(). Evite esto emitiendo una operación NOP general antes de que SQPOLL haga algo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: hisilicon/sec: corrige la pérdida de memoria para la liberación de recursos de segundo El AIV es uno de los recursos de SEC. Al liberar recursos, es necesario liberar los recursos AIV al mismo tiempo. De lo contrario, se produce una pérdida de memoria. La liberación de recursos aiv se agrega a la función de liberación de recursos sec.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: crea pruebas de generación de eventos solo como módulos. Los módulos de prueba de generación de eventos kprobes y synth agregan eventos y bloquean (obtienen una referencia) esas referencias de archivos de eventos en la función de inicio del módulo, y desbloquean y elimínelo en la función de salida del módulo. Esto se debe a que están diseñados para jugar como módulos. Si hacemos que esos módulos estén integrados, esos eventos quedan bloqueados en el kernel y nunca se eliminan. Esto provoca una falla en la autoprueba del evento kprobe como se muestra a continuación. [97.349708] ------------[ cortar aquí ]------------ [ 97.353453] ADVERTENCIA: CPU: 3 PID: 1 en kernel/trace/trace_kprobe.c :2133 kprobe_trace_self_tests_init+0x3f1/0x480 [ 97.357106] Módulos vinculados en: [ 97.358488] CPU: 3 PID: 1 Comm: swapper/0 No contaminado 6.9.0-g699646734ab5-dirty #14 [ 97.361556] Nombre de hardware: PC estándar (i440FX + PIIX, 1996), BIOS 1.15.0-1 01/04/2014 [ 97.363880] RIP: 0010:kprobe_trace_self_tests_init+0x3f1/0x480 [ 97.365538] Código: a8 24 08 82 e9 ae fd ff ff 90 0f 0b 90 48 c7 c7 e5 aa 0b 82 e9 ee fc ff ff 90 0f 0b 90 48 c7 c7 2d 61 06 82 e9 8e fd ff 90 <0f> 0b 90 48 c7 c7 33 0b 0c 82 89 c6 e8 6e 03 1f ff 41 ff c7 e9 0 [ 97.370429] RSP: 0000:ffffc90000013b50 EFLAGS: 00010286 [ 97.371852] RAX: 00000000ffffff0 RBX: ffff888005919c00 RCX: 0000000000000000 [ 97.3 73829] RDX: ffff888003f40000 RSI: ffffffff8236a598 RDI: ffff888003f40a68 [ 97.375715] RBP: 00000000000000000 R08: 0000000000000001 R09: 000000000 [97.377675] R10: ffffffff811c9ae5 R11: ffffffff8120c4e0 R12: 0000000000000000 [ 97.379591] R13: 00000000000000001 R14: 0000000000000015 R15: 0000000000 000000 [ 97.381536] FS: 0000000000000000(0000) GS:ffff88807dcc0000(0000) knlGS:000000000000000000 [ 97.383813] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 97.385449] CR2: 0000000000000000 CR3: 0000000002244000 CR4: 00000000000006b0 [ 97.387347] DR0: 0000000000 000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 97.389277] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 97.3911 96] Seguimiento de llamadas: [97.391967] < TAREA> [ 97.392647] ? __advertir+0xcc/0x180 [ 97.393640] ? kprobe_trace_self_tests_init+0x3f1/0x480 [97.395181]? report_bug+0xbd/0x150 [97.396234]? handle_bug+0x3e/0x60 [97.397311]? exc_invalid_op+0x1a/0x50 [97.398434]? asm_exc_invalid_op+0x1a/0x20 [97.399652]? trace_kprobe_is_busy+0x20/0x20 [97.400904]? tracing_reset_all_online_cpus+0x15/0x90 [97.402304]? kprobe_trace_self_tests_init+0x3f1/0x480 [97.403773]? init_kprobe_trace+0x50/0x50 [ 97.404972] do_one_initcall+0x112/0x240 [ 97.406113] do_initcall_level+0x95/0xb0 [ 97.407286] ? kernel_init+0x1a/0x1a0 [97.408401] do_initcalls+0x3f/0x70 [97.409452] kernel_init_freeable+0x16f/0x1e0 [97.410662] ? rest_init+0x1f0/0x1f0 [97.411738] kernel_init+0x1a/0x1a0 [97.412788] ret_from_fork+0x39/0x50 [97.413817] ? rest_init+0x1f0/0x1f0 [ 97.414844] ret_from_fork_asm+0x11/0x20 [ 97.416285] [ 97.417134] sello de evento irq: 13437323 [ 97.418376] hardirqs habilitado por última vez en (13437337): ffffff8110bc0c>] console_unlock+0x11c/0x150 [ 97.421285] hardirqs deshabilitado por última vez en (13437370): [] console_unlock+0x101/0x150 [ 97.423838] softirqs habilitado por última vez en (13437366): [] handle_softirqs+0x23f/0x2a0 [ 97.426450] softirqs se deshabilitó por última vez en (13437393 ): [] __irq_exit_rcu+0x66/0xd0 [ 97.428850] ---[ end trace 0000000000000000 ]--- Y además, como no podemos limpiar el archivo Dynamic_event, ftracetest también falla. Para evitar estos problemas, cree estas pruebas solo como módulos.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: netpoll: Corrige condición de ejecución en netpoll_owner_active KCSAN detectó una condición de ejecución en netpoll: ERROR: KCSAN: data-race en net_rx_action / netpoll_send_skb escribe (marcado) en 0xffff8881164168b0 de 4 bytes por interrupción en CPU 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) leído en 0xffff8881164168b0 de 4 bytes por tarea 1 en la CPU 2 : netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) valor cambiado: 0x0000000a -> 0xffffffff Esto sucede porque netpoll_owner_active() necesita verificar si la CPU actual es la propietaria del bloqueo, tocando napi->poll_owner de forma no atómica. El campo ->poll_owner contiene la CPU actual que mantiene el bloqueo. Utilice una lectura atómica para comprobar si el propietario de la encuesta es la CPU actual.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netrom: corrige una pérdida de memoria en nr_heartbeat_expiry() syzbot informó una pérdida de memoria en nr_create() [0]. El commit 409db27e3a2e ("netrom: Reparar el use-after-free de un socket de escucha") agregó sock_hold() a la función nr_heartbeat_expiry(), donde a) un socket tiene un indicador SOCK_DESTROY ob) un socket de escucha tiene un indicador SOCK_DEAD. Pero en el caso "a", cuando se establece el indicador SOCK_DESTROY, el descriptor de archivo ya se ha cerrado y se ha llamado a la función nr_release(). Por lo tanto, no tiene sentido mantener el recuento de referencias porque nadie llamará a otro nr_destroy_socket() y lo pondrá como en el caso "b". nr_connect nr_establecer_data_link nr_start_heartbeat nr_release interruptor (nr->estado) caso NR_STATE_3 nr->estado = NR_STATE_2 sock_set_flag(sk, SOCK_DESTROY); nr_rx_frame nr_process_rx_frame interruptor (nr->estado) caso NR_STATE_2 nr_state2_machine() nr_disconnect() nr_sk(sk)->estado = NR_STATE_0 sock_set_flag(sk, SOCK_DEAD) nr_heartbeat_expiry interruptor (nr->estado) caso NR_STATE_0 if (sock_flag(sk, OCK_DESTROY) || (sk->sk_state == TCP_LISTEN && sock_flag(sk, SOCK_DEAD))) sock_hold() // ( !!! ) nr_destroy_socket() Para solucionar la pérdida de memoria, llamemos a sock_hold() solo para un socket de escucha. Encontrado por InfoTeCS en nombre del Centro de verificación de Linux (linuxtesting.org) con Syzkaller. [0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/tcp_ao: No filtrar ao_info en la ruta de error. Parece que lo introduje junto con TCP_AO_CMDF_AO_REQUIRED, en la versión 5 [1] de los parches TCP-AO. Es bastante frustrante que, teniendo todas estas autopruebas que he escrito, ejecutar kmemtest y kcov siempre estuviera pendiente. [1]: https://lore.kernel.org/netdev/20230215183335.800122-5-dima@arista.com/

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: dmaengine: xilinx: xdma: corrige la sincronización de datos en xdma_channel_isr() Solicita el bloqueo de vchan antes de usar xdma->stop_request.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: ti: k3-udma-glue: Fix of_k3_udma_glue_parse_chn_by_id() La función auxiliar of_k3_udma_glue_parse_chn_by_id() invoca erróneamente "of_node_put()" en el nodo de dispositivo "udmax_np" que se le pasó , sin haber incrementado su recuento de referencias en ningún momento. Arreglalo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rxe: corrige la comprobación de la longitud del respondedor para los paquetes de solicitud UD. Según la especificación IBA: si se detecta un paquete de solicitud UD con una longitud no válida, la solicitud será una solicitud no válida y El respondedor lo dejará caer silenciosamente. Luego, el respondedor espera un nuevo paquete de solicitud. El commit 689c5421bfe0 ("RDMA/rxe: corregir la verificación incorrecta de la longitud del respondedor") pospone la verificación de la longitud del respondedor para los QP de UD en la función `copy_data`. Pero introduce un problema de regresión para los QP de UD. Cuando el tamaño del paquete es demasiado grande para caber en el búfer de recepción. `copy_data` devolverá el código de error -EINVAL. Entonces `send_data_in` devolverá RESPST_ERR_MALFORMED_WQE. UD QP pasará al estado ERROR.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cpufreq: amd-pstate: corrige la pérdida de memoria en la salida del EPP de la CPU La memoria cpudata de kzalloc() en amd_pstate_epp_cpu_init() no se libera en la función de salida análoga, así que solucione eso. [rjw: ediciones de asunto y registro de cambios]

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ext4: arreglar ratelimit_state no inicializado->bloquear acceso en __ext4_fill_super() En la siguiente concurrencia accederemos al rs->lock no inicializado: ext4_fill_super ext4_register_sysfs // sysfs registrado msg_ratelimit_interval_ms // Otros procesos modificar rs->interval a // distinto de cero a través de msg_ratelimit_interval_ms ext4_orphan_cleanup ext4_msg(sb, KERN_INFO, "Errores en el sistema de archivos, " __ext4_msg ___ratelimit(&(EXT4_SB(sb)->s_msg_ratelimit_state) if (!rs->interval) // hacer nada si el intervalo es 0 devuelve 1; ->s_msg_ratelimit_state , 5 * HZ, 10); raw_spin_lock_init(&rs->lock); // inicia rs->lock aquí y obtiene el siguiente dump_stack: ==================== ===================================== INFORMACIÓN: intentando registrar una clave no estática. El código está bien pero necesita una anotación de bloqueo, ¿o tal vez no inicializó este objeto antes de usarlo? apagando el validador de corrección de bloqueo. CPU: 12 PID: 753 Comunicaciones: montaje contaminado: GE 6.7.0-rc6-next-20231222 #504 [...] Seguimiento de llamadas: dump_stack_lvl+0xc5/0x170 dump_stack+0x18/0x30 Register_lock_class+0x740/0x7c0 __lock_acquire+0x69/ 0x13a0 lock_acquire+0x120/0x450 _raw_spin_trylock+0x98/0xd0 ___ratelimit+0xf6/0x220 __ext4_msg+0x7f/0x160 [ext4] ext4_orphan_cleanup+0x665/0x740 [ext4] 0x2b10 [ext4] text4_fill_super+0x14d/0x360 [ext4] [. ..] ================================================= ========== Normalmente el intervalo es 0 hasta que se inicializa s_msg_ratelimit_state, por lo que ___ratelimit() no hace nada. Pero el registro de sysfs precede a la inicialización de rs->lock, por lo que es posible cambiar rs->interval a un valor distinto de cero a través de la interfaz msg_ratelimit_interval_ms de sysfs mientras rs->lock no está inicializado, y luego una llamada a ext4_msg desencadena el problema al accediendo a un rs->lock no inicializado. Por lo tanto, registre sysfs después de que se completen todas las inicializaciones para evitar este tipo de problemas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: ena: agregue validación para la coherencia de los descriptores de finalización. Valide que el indicador "primer" esté configurado solo para el primer descriptor en paquetes de múltiples búfer. En caso de un descriptor no válido, se producirá un reinicio. Se ha agregado un nuevo motivo de reinicio para la corrupción de datos RX.