Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: client: fix TCP timers deadlock after rmmod Commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") corrigió un UAF de netns habilitando manualmente el recuento de referencias de sockets (sk->sk_net_refcnt=1 y sock_inuse_add(net, 1)). La razón por la que el parche funcionó para ese error fue porque ahora tenemos referencias a netns (get_net_track() obtiene una referencia internamente) y se liberan correctamente (internamente, en __sk_destruct()), pero solo porque se configuró sk->sk_net_refcnt. Problema: (esto sucede independientemente de CONFIG_NET_NS_REFCNT_TRACKER y sin importar si es init_net u otro) Establecer sk->sk_net_refcnt=1 *manualmente* y *después* de la creación del socket no solo está fuera del alcance de cifs, sino que también es técnicamente incorrecto: se establece condicionalmente en función de los sockets del usuario (=1) frente a los del kernel (=0). Y las implementaciones de net/ parecen basar sus operaciones de espacio de usuario frente a kernel en ello. p. ej., al cerrar el socket TCP, los temporizadores TCP no se borran porque sk->sk_net_refcnt=1: (cf. commit 151c9c724d05 ("tcp: finalizar correctamente los temporizadores para los sockets del kernel")) net/ipv4/tcp.c: void tcp_close(struct sock *sk, long timeout) { lock_sock(sk); __tcp_close(sk, timeout); release_sock(sk); if (!sk->sk_net_refcnt) inet_csk_clear_xmit_timers_sync(sk); sock_put(sk); } Esto arrojará una advertencia de lockdep y luego, como se esperaba, un bloqueo en tcp_write_timer(). Una forma de reproducir esto es ejecutando el reproductor desde ef7134c7fc48 y luego 'rmmod cifs'. Unos segundos más tarde, aparece la advertencia de bloqueo/lockdep. Solución: No deberíamos meternos con los componentes internos del socket nosotros mismos, así que no configure sk_net_refcnt manualmente. También cambie __sock_create() a sock_create_kern() para que sea más explícito. En cuanto a los espacios de nombres de red que no son init_net, lo tratamos de la mejor manera que podemos: mantenemos una referencia netns adicional para server->ssocket y la descartamos cuando se libera. Esto garantiza que netns siga existiendo siempre que necesitemos crear o destruir server->ssocket, pero no está directamente vinculado a él.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: IDLETIMER: Corrección de un posible bloqueo de ABBA La eliminación de la última regla que hace referencia a un temporizador inactivo determinado puede ocurrir al mismo tiempo que una lectura de su archivo en sysfs: | ======================================================== | ADVERTENCIA: se detectó una posible dependencia de bloqueo circular | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 No contaminado | ------------------------------------------------------ | iptables/3303 está intentando adquirir el bloqueo: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20 | | pero la tarea ya tiene el bloqueo: | ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v] | | cuyo bloqueo ya depende del nuevo bloqueo. Un reproductor simple es: | #!/bin/bash | | mientras es verdadero; hacer | iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | hecho & | mientras es verdadero; hacer | cat /sys/class/xt_idletimer/timers/testme >/dev/null | Evite esto liberando list_mutex inmediatamente después de eliminar el elemento de la lista y luego continúe con el desmontaje.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: renesas: rswitch: evitar el uso posterior a la ejecución de un nodo del árbol de dispositivos El nodo del árbol de dispositivos guardado en la estructura rswitch_device se utiliza en varias ubicaciones de controladores. Por lo tanto, pasar este nodo a of_node_put() después del primer uso es incorrecto. Mueva of_node_put() para este nodo a las rutas de salida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfs: desbloquear inodos al generar un error fuera de xfs_trans_alloc_dir La depuración de un parche del sistema de archivos con generic/475 provocó que el sistema se bloqueara después de observar las siguientes secuencias en dmesg: XFS (dm-0): error de E/S de metadatos en "xfs_imap_to_bp+0x61/0xe0 [xfs]" en daddr 0x491520 len 32 error 5 XFS (dm-0): error de E/S de metadatos en "xfs_btree_read_buf_block+0xba/0x160 [xfs]" en daddr 0x3445608 len 8 error 5 XFS (dm-0): error de E/S de metadatos en "xfs_imap_to_bp+0x61/0xe0 [xfs]" en daddr 0x138e1c0 len 32 error 5 XFS (dm-0): error de E/S de registro -5 XFS (dm-0): Error de E/S de metadatos (0x1) detectado en xfs_trans_read_buf_map+0x1ea/0x4b0 [xfs] (fs/xfs/xfs_trans_buf.c:311). Apagando el sistema de archivos. XFS (dm-0): Desmonte el sistema de archivos y rectifique los problemas. XFS (dm-0): Error interno dqp->q_ino.reserved < dqp->q_ino.count en la línea 869 del archivo fs/xfs/xfs_trans_dquot.c. Llamador xfs_trans_dqresv+0x236/0x440 [xfs] XFS (dm-0): Corrupción detectada. Desmontar y ejecutar xfs_repair XFS (dm-0): Desmontando el sistema de archivos be6bcbcc-9921-4deb-8d16-7cc94e335fa7 El sistema está atascado en el modo de desmontaje intentando bloquear un par de inodos para que puedan ser purgados. El aviso de corrupción de dquot anterior es una pista de lo que sucedió: una llamada a link() intentó configurar una transacción para vincular un hijo a un directorio. La reserva de cuota para la transacción falló después de que los errores de E/S apagaran el sistema de archivos, pero luego olvidamos desbloquear los inodos al salir. Arreglen eso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: Prevenir posibles bloqueos en la recuperación de errores de conexión de escritura de zona La conexión de escritura de zona para gestionar escrituras en zonas de un dispositivo de bloque zonificado siempre ejecuta un informe de zona siempre que falla una BIO de escritura en una zona. La intención de esto es garantizar que el seguimiento de un puntero de escritura de zona siempre sea correcto para garantizar que la alineación con un puntero de escritura de zona de las BIO de escritura se pueda comprobar en el envío y que siempre podamos emular correctamente las operaciones de anexión de zona utilizando BIO de escritura normales. Sin embargo, este esquema de recuperación de errores introduce un posible bloqueo si se inicia un congelamiento de la cola del dispositivo mientras las BIO todavía están conectadas a una conexión de escritura de zona y una de estas operaciones de escritura falla. En tal caso, el trabajo de recuperación de errores de conexión de escritura de zona de disco se programa y ejecuta una zona de informe. Esto, a su vez, puede dar como resultado una asignación de solicitud en el controlador subyacente para emitir el comando de zonas de informe al dispositivo. Pero con la congelación de la cola del dispositivo ya iniciada, esta asignación se bloqueará, lo que evitará la ejecución de la zona de informe y la continuación del procesamiento de las BIO conectadas. Como los BIO conectados contienen una referencia de uso de cola, la congelación de la cola en sí nunca se completará, lo que dará como resultado un bloqueo. Evite este problema eliminando por completo del código de conexión de escritura de zona el uso de operaciones de zonas de informe después de una operación de escritura fallida, y en su lugar, confíe en el usuario del dispositivo para ejecutar zonas de informe, restablecer la zona, finalizar la zona o dejar de escribir en el dispositivo (que es un patrón bastante común para los sistemas de archivos que se degradan a solo lectura después de fallas de escritura). Este no es un requisito irrazonable ya que todas las aplicaciones, los FS y el mapeador de dispositivos que se comportan bien ya usan zonas de informe para recuperarse de errores de escritura siempre que sea posible al comparar la posición actual de un puntero de escritura de zona con lo que suponen sobre la posición. Los cambios para eliminar la recuperación automática de errores son los siguientes: - Eliminar por completo el trabajo de recuperación de errores y sus recursos asociados (cabeza de lista de conexión de escritura de zona, lista de errores de disco y estructura de trabajo zone_wplugs_work de disco). Esto también elimina las funciones disk_zone_wplug_set_error() y disk_zone_wplug_clear_error(). - Cambie el indicador de complemento de escritura de zona BLK_ZONE_WPLUG_ERROR a BLK_ZONE_WPLUG_NEED_WP_UPDATE. Este nuevo indicador se establece para un complemento de escritura de zona siempre que falla una operación de escritura dirigida a la zona del complemento de escritura de zona. Este indicador indica que el desplazamiento del puntero de escritura de zona no es confiable y que debe actualizarse cuando se ejecuta la siguiente zona de informe, zona de reinicio, zona de finalización o revalidación de disco. - Modifique blk_zone_write_plug_bio_endio() para establecer el indicador BLK_ZONE_WPLUG_NEED_WP_UPDATE para la zona de destino de un BIO de escritura fallida. - Modifique la función disk_zone_wplug_set_wp_offset() para borrar este nuevo indicador, implementando así la recuperación de un desplazamiento correcto del puntero de escritura con las operaciones de zona de reinicio (todas) y zona de finalización. - Modificar blkdev_report_zones() para que siempre use la devolución de llamada disk_report_zones_cb() de modo que se pueda llamar a disk_zone_wplug_sync_wp_offset() para cualquier zona marcada con el indicador BLK_ZONE_WPLUG_NEED_WP_UPDATE. ---- truncada ----

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: Se corrige el uso de IPI en kfence_protect_page(). flush_tlb_kernel_range() puede usar IPI para vaciar las TLB de todos los núcleos, lo que activa la siguiente advertencia cuando las irq están deshabilitadas: [ 3.455330] ADVERTENCIA: CPU: 1 PID: 0 en kernel/smp.c:815 smp_call_function_many_cond+0x452/0x520 [ 3.456647] Módulos vinculados en: [ 3.457218] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 No contaminado 6.12.0-rc7-00010-g91d3de7240b8 #1 [ 3.457416] Nombre del hardware: QEMU QEMU Virtual Machine, BIOS [ 3.457633] epc : función_llamada_smp_muchas_cond+0x452/0x520 [ 3.457736] ra : en_cada_máscara_cond_de_cpu+0x1e/0x30 [ 3.457786] epc : ffffffff800b669a ra : ffffffff800b67c2 sp : ff2000000000bb50 [ 3.457824] gp : ffffffff815212b8 tp : ff6000008014f080 t0 : 000000000000003f [ 3.457859] t1 : ffffffff815221e0 t2 : 000000000000000f s0: ff2000000000bc10 [3.457920] s1: 0000000000000040 a0: ffffffff815221e0 a1: 0000000000000001 [3.457953] a2 : 0000000000010000 a3 : 0000000000000003 a4 : 0000000000000000 [ 3.458006] a5 : 00000000000000000 a6 : ffffffffffffffff a7 : 0000000000000000 [ 3.458042] s2 : ffffffff815223be s3 : 00fffffffffff000 s4 : ff600001ffe38fc0 [ 3.458076] s5 : ff600001ff950d00 s6 : 0000000200000120 s7: 00000000000000001 [3.458109] s8: 0000000000000001 s9: ff60000080841ef0 s10: 0000000000000001 [ 3.458141] t11: ffffffff81524812 t3 : 0000000000000001 t4 : ff60000080092bc0 [ 3.458172] t5 : 0000000000000000 t6 : ff200000000236d0 [ 3.458203] estado: 0000000200000100 dirección incorrecta: ffffffff800b669a causa: 0000000000000003 [ 3.458373] [] función_llamada_smp_muchas_cond+0x452/0x520 [ 3.458593] [] en cada máscara de condición de CPU+0x1e/0x30 [ 3.458625] [] __flush_tlb_range+0x118/0x1ca [ 3.458656] [] flush_tlb_kernel_range+0x1e/0x26 [ 3.458683] [] kfence_protect+0xc0/0xce [ 3.458717] [] kfence_guarded_free+0xc6/0x1c0 [ 3.458742] [] __kfence_free+0x62/0xc6 [ 3.458764] [] kfree+0x106/0x32c [ 3.458786] [] detach_buf_split+0x188/0x1a8 [ 3.458816] [] virtqueue_get_buf_ctx+0xb6/0x1f6 [ 3.458839] [] virtqueue_get_buf+0xe/0x16 [ 3.458880] [] virtblk_done+0x5c/0xe2 [ 3.458908] [] interrupción_de_vring+0x6a/0x74 [ 3.458930] [] __controlador_de_evento_irq_percpu+0x7c/0xe2 [ 3.458956] [] control_de_evento_irq+0x3c/0x86 [ 3.458978] [] control_de_irq_simple+0x9e/0xbe [ 3.459004] [] control_de_dominio_genérico_irq+0x1c/0x2a [ 3.459027] [] imsic_handle_irq+0xba/0x120 [ 3.459056] [] generic_handle_domain_irq+0x1c/0x2a [ 3.459080] [] riscv_intc_aia_irq+0x24/0x34 [ 3.459103] [] handle_riscv_irq+0x2e/0x4c [ 3.459133] [] call_on_irq_stack+0x32/0x40 Por lo tanto, solo limpie la TLB local y deje que la gestión de errores de página de kfence se ocupe de los errores que podrían Esto ocurre cuando un núcleo tiene una versión antigua de PTE protegida almacenada en caché en su TLB. Esto genera posibles imprecisiones que pueden tolerarse al usar kfence.

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: nilfs2: evitar el uso de inodo eliminado syzbot informó una ADVERTENCIA en nilfs_rmdir. [1] Debido a que el mapa de bits del inodo está dañado, un inodo con un número de inodo que debería existir como un archivo ".nilfs" fue reasignado por nilfs_mkdir para "file0", lo que provocó una duplicación de inodo durante la ejecución. Y esto causa un desbordamiento de i_nlink en operaciones rmdir. El inodo es utilizado dos veces por la misma tarea para desmontar y eliminar los directorios ".nilfs" y "file0", lo que activa una advertencia en nilfs_rmdir. Evite este problema, verifique i_nlink en nilfs_iget(), si es 0, significa que este inodo ha sido eliminado y se ejecuta iput para recuperarlo. [1] ADVERTENCIA: CPU: 1 PID: 5824 en fs/inode.c:407 drop_nlink+0xc4/0x110 fs/inode.c:407 ... Seguimiento de llamadas: nilfs_rmdir+0x1b0/0x250 fs/nilfs2/namei.c:342 vfs_rmdir+0x3a3/0x510 fs/namei.c:4394 do_rmdir+0x3b5/0x580 fs/namei.c:4453 __do_sys_rmdir fs/namei.c:4472 [en línea] __se_sys_rmdir fs/namei.c:4470 [en línea] __x64_sys_rmdir+0x47/0x50 fs/namei.c:4470 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

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: accel/ivpu: Corregir WARN en ivpu_ipc_send_receive_internal() Mover pm_runtime_set_active() a ivpu_pm_init() para que cuando ivpu_ipc_send_receive_internal() se ejecute antes de ivpu_pm_enable() ya tenga el estado de tiempo de ejecución correcto, incluso si la última reanudación no fue exitosa.

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: 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.