Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: accel/ivpu: corrige un error de protección general en ivpu_bo_list(). Comprueba si ctx no es NULL antes de acceder a sus campos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: iso: Corregir bloqueo circular en iso_conn_big_sync Esto corrige la advertencia de dependencia de bloqueo circular a continuación, al reelaborar iso_sock_recvmsg, para garantizar que el bloqueo del socket siempre se libere antes de llamar a una función que bloquea hdev. [ 561.670344] ========================================================= [ 561.670346] ADVERTENCIA: posible dependencia de bloqueo circular detectada [ 561.670349] 6.12.0-rc6+ #26 No contaminado [ 561.670351] ------------------------------------------------------ [ 561.670353] iso-tester/3289 está intentando adquirir bloqueo: [ 561.670355] ffff88811f600078 (&hdev->lock){+.+.}-{3:3}, en: iso_conn_big_sync+0x73/0x260 [bluetooth] [ 561.670405] pero la tarea ya tiene el bloqueo: [ 561.670407] ffff88815af58258 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0}, en: iso_sock_recvmsg+0xbf/0x500 [bluetooth] [ 561.670450] cuyo bloqueo ya depende del nuevo bloqueo. [ 561.670452] la cadena de dependencia existente (en orden inverso) es: [ 561.670453] -> #2 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0}: [ 561.670458] lock_acquire+0x7c/0xc0 [ 561.670463] lock_sock_nested+0x3b/0xf0 [ 561.670467] bt_accept_dequeue+0x1a5/0x4d0 [bluetooth] [ 561.670510] iso_sock_accept+0x271/0x830 [bluetooth] [ 561.670547] do_accept+0x3dd/0x610 [ 561.670550] __sys_accept4+0xd8/0x170 [ 561.670553] __x64_sys_accept+0x74/0xc0 [ 561.670556] x64_sys_call+0x17d6/0x25f0 [ 561.670559] hacer_syscall_64+0x87/0x150 [ 561.670563] entrada_SYSCALL_64_after_hwframe+0x76/0x7e [ 561.670567] -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}: [ 561.670571] bloqueo_adquirir+0x7c/0xc0 [ 561.670574] lock_sock_nested+0x3b/0xf0 [ 561.670577] iso_sock_listen+0x2de/0xf30 [bluetooth] [ 561.670617] __sys_listen_socket+0xef/0x130 [ 561.670620] __x64_sys_listen+0xe1/0x190 [ 561.670623] x64_sys_call+0x2517/0x25f0 [ 561.670626] hacer_syscall_64+0x87/0x150 [ 561.670629] entrada_SYSCALL_64_después_de_hwframe+0x76/0x7e [ 561.670632] -> #0 (&hdev->lock){+.+.}-{3:3}: [ 561.670636] __lock_acquire+0x32ad/0x6ab0 [ 561.670639] lock_acquire.part.0+0x118/0x360 [ 561.670642] lock_acquire+0x7c/0xc0 [ 561.670644] __mutex_lock+0x18d/0x12f0 [ 561.670647] mutex_lock_nested+0x1b/0x30 [ 561.670651] iso_conn_big_sync+0x73/0x260 [bluetooth] [ 561.670687] iso_sock_recvmsg+0x3e9/0x500 [bluetooth] [561.670722] sock_recvmsg+0x1d5/0x240 [561.670725] sock_read_iter+0x27d/0x470 [561.670727] vfs_read+0x9a0/0xd30 [561.670731] ksys_read+0x1a8/0x250 [561.670733] __x64_sys_read+0x72/0xc0 [561.670736] x64_sys_call+0x1b12/0x25f0 [561.670738] do_syscall_64+0x87/0x150 [ 561.670741] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 561.670744] otra información que podría ayudarnos a depurar esto: [ 561.670745] La cadena existe de: &hdev->lock --> sk_lock-AF_BLUETOOTH-BTPROTO_ISO --> sk_lock-AF_BLUETOOTH [ 561.670751] Posible escenario de bloqueo inseguro: [ 561.670753] CPU0 CPU1 [ 561.670754] ---- ---- [ 561.670756] lock(sk_lock-AF_BLUETOOTH); [ 561.670758] bloqueo(sk_lock AF_BLUETOOTH-BTPROTO_ISO); [ 561.670761] bloqueo(sk_lock-AF_BLUETOOTH); [ 561.670764] bloqueo(&hdev->lock); [ 561.670767] *** BLOQUEO INTERMEDIO ***

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: Fix potential deadlock while frozen queue and acquires sysfs_lock Para almacenar un valor en un atributo de cola, la función queue_attr_store primero congela la cola (->q_usage_counter(io)) y luego adquiere ->sysfs_lock. Esto no parece correcto ya que el orden habitual debería ser adquirir ->sysfs_lock antes de congelar la cola. Este orden incorrecto provoca el siguiente splat lockdep que siempre podemos reproducir simplemente accediendo al archivo /sys/kernel/debug usando el comando ls: [ 57.597146] ADVERTENCIA: posible dependencia de bloqueo circular detectada [ 57.597154] 6.12.0-10553-gb86545e02e8c #20 Tainted: GW [ 57.597162] ------------------------------------------------------ [ 57.597168] ls/4605 está intentando adquirir el bloqueo: [ 57.597176] c00000003eb56710 (&mm->mmap_lock){++++}-{4:4}, at: __might_fault+0x58/0xc0 [ 57.597200] pero la tarea ya tiene el bloqueo: [ 57.597207] c0000018e27c6810 (&sb->s_type->i_mutex_key#3){++++}-{4:4}, en: iterate_dir+0x94/0x1d4 [ 57.597226] cuyo bloqueo ya depende del nuevo bloqueo. [ 57.597233] la cadena de dependencia existente (en orden inverso) es: [ 57.597241] -> #5 (&sb->s_type->i_mutex_key#3){++++}-{4:4}: [ 57.597255] down_write+0x6c/0x18c [ 57.597264] start_creating+0xb4/0x24c [ 57.597274] debugfs_create_dir+0x2c/0x1e8 [ 57.597283] blk_register_queue+0xec/0x294 [ 57.597292] add_disk_fwnode+0x2e4/0x548 [ 57.597302] brd_alloc+0x2c8/0x338 [ 57.597309] brd_init+0x100/0x178 [ 57.597317] hacer_una_initcall+0x88/0x3e4 [ 57.597326] kernel_init_freeable+0x3cc/0x6e0 [ 57.597334] kernel_init+0x34/0x1cc [ 57.597342] retirar_del_subproceso_usuario_kernel+0x14/0x1c [ 57.597350] -> #4 (&q->debugfs_mutex){+.+.}-{4:4}: [ 57.597362] __mutex_lock+0xfc/0x12a0 [ 57.597370] blk_register_queue+0xd4/0x294 [ 57.597379] add_disk_fwnode+0x2e4/0x548 [ 57.597388] brd_alloc+0x2c8/0x338 [ 57.597395] brd_init+0x100/0x178 [ 57.597402] hacer_una_llamada_inicio+0x88/0x3e4 [ 57.597410] kernel_init_freeable+0x3cc/0x6e0 [ 57.597418] kernel_init+0x34/0x1cc [ 57.597426] ret_desde_hilo_usuario_kernel+0x14/0x1c [ 57.597434] -> #3 (&q->sysfs_lock){+.+.}-{4:4}: [ 57.597446] __mutex_lock+0xfc/0x12a0 [ 57.597454] queue_attr_store+0x9c/0x110 [ 57.597462] sysfs_kf_write+0x70/0xb0 [ 57.597471] kernfs_fop_write_iter+0x1b0/0x2ac [ 57.597480] vfs_write+0x3dc/0x6e8 [ 57.597488] ksys_write+0x84/0x140 [ 57.597495] excepción_de_llamada_del_sistema+0x130/0x360 [ 57.597504] llamada_del_sistema_común+0x160/0x2c4 [ 57.597516] -> #2 (&q->q_contador_de_uso(io)#21){++++}-{0:0}: [ 57.597530] __submit_bio+0x5ec/0x828 [ 57.597538] enviar_bio_noacct_nocheck+0x1e4/0x4f0 [ 57.597547] iomap_readahead+0x2a0/0x448 [ 57.597556] xfs_vm_readahead+0x28/0x3c [ 57.597564] leer_páginas+0x88/0x41c [ 57.597571] page_cache_ra_unbounded+0x1ac/0x2d8 [ 57.597580] filemap_get_pages+0x188/0x984 [ 57.597588] filemap_read+0x13c/0x4bc [ 57.597596] xfs_file_buffered_read+0x88/0x17c [ 57.597605] xfs_file_read_iter+0xac/0x158 [ 57.597614] vfs_read+0x2d4/0x3b4 [ 57.597622] ksys_read+0x84/0x144 [ 57.597629] excepción_llamada_sistema+0x130/0x360 [ 57.597637] llamada_sistema_común+0x160/0x2c4 [ 57.597647] -> #1 (asignación.invalidar_bloqueo#2){++++}-{4:4}: [ 57.597661] lectura_abajo+0x6c/0x220 [ 57.597669] error_mapa_archivo+0x870/0x100c [ 57.597677] error_mapa_archivo_xfs+0xc4/0x18c [ 57.597684] __error_do+0x64/0x164 [ 57.597693] __error_gestionar_mm+0x1274/0x1dac [ 57.597702] handle_mm_fault+0x248/0x48 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: renunciar a rutas más largas que PATH_MAX Si la ruta completa que se va a construir con ceph_mdsc_build_path() resulta ser más larga que PATH_MAX, esta función entrará en un bucle sin fin (de reintento), bloqueando efectivamente toda la tarea. La mayor parte de la máquina queda inutilizable, lo que hace que esta sea una vulnerabilidad de denegación de servicio (DoS) muy simple y efectiva. No puedo imaginar por qué se implementó este reintento, pero me parece bastante inútil y dañino. Eliminémoslo y fallemos con ENAMETOOLONG en su lugar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igb: Se corrige un posible acceso no válido a la memoria en igb_init_module(). pci_register_driver() puede fallar y cuando esto sucede, se debe anular el registro de dca_notifier; de lo contrario, se puede llamar a dca_notifier cuando igb no se instala, lo que genera un acceso no válido a la memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipvs: corrección de UB debido a acceso a pila no inicializado en ip_vs_protocol_init() En determinadas configuraciones del kernel al compilar con Clang/LLVM, el compilador no genera un retorno o salto como instrucción de terminación para ip_vs_protocol_init(), lo que activa la siguiente advertencia de objtool durante el tiempo de compilación: vmlinux.o: advertencia: objtool: ip_vs_protocol_init() pasa a la siguiente función __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6() En tiempo de ejecución, esto provoca un error al intentar cargar el módulo ipvs o un pánico en el tiempo de arranque si ipvs está integrado. El robot de prueba del kernel de Intel ha informado anteriormente de este mismo problema. Al investigar más a fondo tanto en LLVM como en el código del kernel, se revela que se trata de un problema de comportamiento indefinido. ip_vs_protocol_init() utiliza un búfer en pila de 64 caracteres para almacenar los nombres de protocolo registrados y lo deja sin inicializar después de la definición. La función llama a strnlen() al concatenar nombres de protocolo en el búfer. Con CONFIG_FORTIFY_SOURCE, strnlen() realiza un paso adicional para verificar si el último byte del búfer de caracteres de entrada es un carácter nulo (commit 3009f891bb9f ("fortify: Permitir que strlen() y strnlen() pasen longitudes conocidas en tiempo de compilación")). Esto, junto con posiblemente otras configuraciones, hace que se genere la siguiente IR: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 { %1 = alloca [64 x i8], align 16 ... 14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = cargar i8, ptr %15, alinear 1 %17 = cola llamar i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = seleccionar i1 %17, i1 %18, i1 falso br i1 %19, etiqueta %20, etiqueta %23 20: ; preds = %14 %21 = llamar i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ... 23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... } El código anterior calcula la dirección del último carácter en el búfer (valor %15) y luego carga desde él (valor %16). Como el buffer nunca se inicializa, el paso GVN de LLVM marca el valor %16 como indefinido: %13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17 Esto otorga a los pases posteriores (SCCP, en particular) más oportunidades de DCE al propagar más el valor indefinido y, eventualmente, elimina todo después de la carga en la ubicación de la pila no inicializada: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 { %1 = alloca [64 x i8], align 16 ... 12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable } De esta manera, el código nativo generado simplemente pasará a la siguiente función, ya que LLVM no genera ningún código para la instrucción IR inalcanzable y deja la función sin un terminador. Ponga a cero el búfer en la pila para evitar este posible UB.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regulador: axp20x: AXP717: establecer ramp_delay La hoja de datos de AXP717 dice que el retraso de rampa del regulador es 15,625 us/paso, que es 10 mV en nuestro caso. Agregue una macro AXP_DESC_RANGES_DELAY y actualice la macro AXP_DESC_RANGES para expandir a AXP_DESC_RANGES_DELAY con ramp_delay = 0 Para DCDC4, los pasos son 100 mv Agregue una macro AXP_DESC_DELAY y actualice la macro AXP_DESC para expandir a AXP_DESC_DELAY con ramp_delay = 0 Este parche corrige fallas al usar CPU DVFS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: comprobar iparea_offset e ipv6_prefixes_cnt al recibir un mensaje de propuesta Al recibir un mensaje de propuesta en el servidor, el campo iparea_offset y el campo ipv6_prefixes_cnt en el mensaje de propuesta son del cliente remoto y no se puede confiar plenamente en ellos. Especialmente el campo iparea_offset, una vez que se excede el valor máximo, existe la posibilidad de acceder a una dirección incorrecta y puede producirse un bloqueo. Este parche comprueba iparea_offset e ipv6_prefixes_cnt antes de usarlos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/fair: Fix NEXT_BUDDY Adam informa que habilitar NEXT_BUDDY instantáneamente activa una ADVERTENCIA en pick_next_entity(). Mover clear_buddies() hacia arriba antes de los bits de eliminación de cola retrasados garantiza que ningún ->next buddy se retrase. Además, asegúrese de que ningún nuevo ->next buddy comience con retraso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: usar dirección alineada en copy_user_gigantic_page() En el kernel actual, hugetlb_wp() llama a copy_user_large_folio() con la dirección de error. Donde la dirección de error puede no estar alineada con el tamaño de página enorme. Entonces, copy_user_large_folio() puede llamar a copy_user_gigantic_page() con la dirección, mientras que copy_user_gigantic_page() requiere que la dirección esté alineada con el tamaño de página enorme. Por lo tanto, esto puede causar corrupción de memoria o fuga de información. Además, use un nombre más obvio 'addr_hint' en lugar de 'addr' para copy_user_gigantic_page().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: usar dirección alineada en clear_gigantic_page() En el kernel actual, hugetlb_no_page() llama a folio_zero_user() con la dirección de error. Donde la dirección de error puede no estar alineada con el tamaño de página enorme. Entonces, folio_zero_user() puede llamar a clear_gigantic_page() con la dirección, mientras que clear_gigantic_page() requiere que la dirección esté alineada con el tamaño de página enorme. Por lo tanto, esto puede causar corrupción de memoria o fuga de información. Además, use un nombre más obvio 'addr_hint' en lugar de 'addr' para clear_gigantic_page().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: mpc52xx: Agregar cancel_work_sync antes de eliminar el módulo Si eliminamos el módulo que llamará a mpc52xx_spi_remove, liberará 'ms' a través de spi_unregister_controller. mientras que se utilizará el trabajo ms->work. La secuencia de operaciones que puede provocar un error de UAF. Arréglelo asegurándose de que el trabajo se cancele antes de continuar con la desinfección en mpc52xx_spi_remove.