Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: Eliminación del movimiento RTNL para SIOCBRADDIF y SIOCBRDELIF. SIOCBRDELIF se pasa primero a dev_ioctl() y luego a br_ioctl_call(), lo que provoca un movimiento RTNL innecesario y el splat debajo de [0] bajo presión RTNL. Supongamos que el subproceso A intenta desconectar un dispositivo de un puente y el subproceso B intenta eliminar el puente. En dev_ioctl(), el subproceso A aumenta el refcnt del dispositivo puente mediante netdev_hold() y libera RTNL porque el subproceso br_ioctl_call() también vuelve a adquirir RTNL. En la ventana de ejecución, el subproceso B podría adquirir RTNL e intentar eliminar el dispositivo puente. Luego, rtnl_unlock() del subproceso B liberará RTNL y esperará a netdev_put() del subproceso A. Sin embargo, el subproceso A debe mantener RTNL después del desbloqueo en dev_ifsioc(), lo que puede tardar mucho bajo la presión de RTNL, lo que resulta en el splat del subproceso B. Subproceso A (SIOCBRDELIF) Subproceso B (SIOCBRDELBR) ---------------------- ---------------------- sock_ioctl sock_ioctl `- sock_do_ioctl `- br_ioctl_call `- dev_ioctl `- br_ioctl_stub |- rtnl_lock | |- dev_ifsioc ' ' |- dev = __dev_get_by_name(...) |- netdev_hold(dev, ...) . / |- rtnl_unlock ------. | | |- br_ioctl_call `---> |- rtnl_lock Race | | `- br_ioctl_stub |- br_del_bridge Ventana | | | |- dev = __dev_get_by_name(...) | | | Puede tomar mucho tiempo | `- br_dev_delete(dev, ...) | | | bajo presión RTNL | `- unregister_netdevice_queue(dev, ...) | | | | `- rtnl_unlock \ | |- rtnl_lock <-' `- netdev_run_todo | |- ... `- netdev_run_todo | `- rtnl_unlock |- __rtnl_unlock | |- netdev_wait_allrefs_any |- netdev_put(dev, ...) <----------------' Espere la disminución de refcnt y registre splat a continuación Para evitar bloquear SIOCBRDELBR innecesariamente, no llamemos a dev_ioctl() para SIOCBRADDIF y SIOCBRDELIF. En la ruta dev_ioctl(), hacemos lo siguiente: 1. Copiar struct ifreq por get_user_ifreq en sock_do_ioctl() 2. Verificar CAP_NET_ADMIN en dev_ioctl() 3. Llamar a dev_load() en dev_ioctl() 4. Obtener el dev maestro de ifr.ifr_name en dev_ifsioc() 3. se puede hacer por request_module() en br_ioctl_call(), por lo que movemos 1., 2. y 4. a br_ioctl_stub(). Tenga en cuenta que 2. también se verifica más adelante en add_del_if(), pero se realiza mejor antes de RTNL. SIOCBRADDIF y SIOCBRDELIF se han procesado en dev_ioctl() desde la era anterior a Git, y no parece haber una razón específica para procesarlos allí. [0]: unregister_netdevice: esperando a que wpan3 quede libre. Recuento de uso = 2 ref_tracker: wpan3@ffff8880662d8608 tiene 1/1 usuarios en __netdev_tracker_alloc include/linux/netdevice.h:4282 [en línea] netdev_hold include/linux/netdevice.h:4311 [en línea] dev_ifsioc+0xc6a/0x1160 net/core/dev_ioctl.c:624 dev_ioctl+0x255/0x10c0 net/core/dev_ioctl.c:826 sock_do_ioctl+0x1ca/0x260 net/socket.c:1213 sock_ioctl+0x23a/0x6c0 net/socket.c:1318 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:906 [en línea] __se_sys_ioctl fs/ioctl.c:892 [en línea] __x64_sys_ioctl+0x1a4/0x210 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de la ejecución de recuento de referencias de grupos de bloques en btrfs_create_pending_block_groups(). La creación de grupos de bloques se realiza en dos fases, lo que resulta en una propiedad poco intuitiva: un grupo de bloques se puede asignar/desasignar después de que btrfs_make_block_group() lo añada a space_info con btrfs_add_bg_to_space_info(), pero antes de que la creación se complete por completo en btrfs_create_pending_block_groups(). Como resultado, es posible que un grupo de bloques quede sin usar y que se invoque 'btrfs_mark_bg_unused' simultáneamente con 'btrfs_create_pending_block_groups'. Esto causa varios problemas, que se solucionaron con la bandera de grupo de bloques 'BLOCK_GROUP_FLAG_NEW'. Sin embargo, esta corrección no está del todo completa. Dado que no utiliza el bloqueo de bloques no utilizados (unused_bg_lock), es posible que se produzca la siguiente ejecución: btrfs_create_pending_block_groups btrfs_mark_bg_unused if list_empty // false list_del_init clear_bit else if (test_bit) // true list_move_tail. Y llegamos al mismo estado de recuento de referencias erróneo y new_bgs no válido para la limpieza de transacciones, que BLOCK_GROUP_FLAG_NEW pretendía evitar. El aspecto de recuento de referencias erróneo generará una advertencia como: [1272.943527] refcount_t: underflow; use-after-free. [1272.943967] ADVERTENCIA: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs] [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G W 6.14.0-rc5+ #108 [1272.946368] Tainted: [W]=WARN [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs] [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110 [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282 [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000 [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268 [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0 [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0 [1272.952850] FS: 0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000 [1272.953458] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0 [1272.954474] Call Trace: [1272.954655] [1272.954812] ? refcount_warn_saturate+0xba/0x110 [1272.955173] ? __warn.cold+0x93/0xd7 [1272.955487] ? refcount_warn_saturate+0xba/0x110 [1272.955816] ? report_bug+0xe7/0x120 [1272.956103] ? handle_bug+0x53/0x90 [1272.956424] ? exc_invalid_op+0x13/0x60 [1272.956700] ? asm_exc_invalid_op+0x16/0x20 [1272.957011] ? refcount_warn_saturate+0xba/0x110 [1272.957399] btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs] [1272.957853] btrfs_put_block_group.cold+0x5d/0x8e [btrfs] [1272.958289] btrfs_discard_workfn+0x194/0x380 [btrfs] [1272.958729] process_one_work+0x130/0x290 [1272.959026] worker_thread+0x2ea/0x420 [1272.959335] ? __pfx_worker_thread+0x10/0x10 [1272.959644] kthread+0xd7/0x1c0 [1272.959872] ? __pfx_kthread+0x10/0x10 [1272.960172] ret_from_fork+0x30/0x50 [1272.960474] ? __pfx_kthread+0x10/0x10 [1272.960745] ret_from_fork_asm+0x1a/0x30 [1272.961035] [1272.961238] ---[ end trace 0000000000000000 ]--- Aunque también los hemos visto en la función de trabajo de descarte asíncrono. Es más probable que ocurra después de finalizar una reubicación que cancela el descarte, desmantela el grupo de bloques, etc. Solucione esto completamente desmantelando el bloqueo de ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no modificar la matriz de fragmentos del sistema en btrfs_validate_super(). El commit 2a9bb78cfd36 ("btrfs: validar la matriz de fragmentos del sistema en btrfs_validate_super()") introduce una llamada a validate_sys_chunk_array() en btrfs_validate_super(), que modifica el valor de ret establecido previamente. Esto invalida las comprobaciones de validez realizadas previamente, lo que permite que btrfs intente montar sistemas de archivos no válidos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: bnxt: se corrige el acceso fuera de rango de la matriz vnic_info. La cola bnxt_queue_{start | stop}() accede a vnic_info tanto como está asignado, lo que indica bp->nr_vnics. Por lo tanto, no debería alcanzar bp->vnic_info[bp->nr_vnics].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evitar el registro en diario de la actualización de sb en caso de error si el diario se está destruyendo. Actualmente, siempre aplicamos BUG_ON al intentar iniciar una transacción en un diario marcado con JBD2_UNMOUNT, ya que esto nunca debería ocurrir. Sin embargo, mientras ltp ejecutaba pruebas de estrés, se observó que en caso de algunas rutas de gestión de errores, es posible que update_super_work inicie una transacción después de que el diario se destruya, por ejemplo: (umount) ext4_kill_sb kill_block_super generic_shutdown_super sync_filesystem /* commits all txns */ evict_inodes /* might start a new txn */ ext4_put_super flush_work(&sbi->s_sb_upd_work) /* flush the workqueue */ jbd2_journal_destroy journal_kill_thread journal->j_flags |= JBD2_UNMOUNT; jbd2_journal_commit_transaction jbd2_journal_get_descriptor_buffer jbd2_journal_bmap ext4_journal_bmap ext4_map_blocks ... ext4_inode_error ext4_handle_error schedule_work(&sbi->s_sb_upd_work) /* work queue kicks in */ update_super_work jbd2_journal_start start_this_handle BUG_ON(journal->j_flags & JBD2_UNMOUNT) Por lo tanto, se introduce un nuevo indicador de montaje para indicar que el diario se está destruyendo y solo se realiza una actualización registrada (y diferida) de sb si este indicador no está configurado. De lo contrario, simplemente se recurre a una confirmación no registrada. Además, en la ruta de destrucción del diario, tenemos la siguiente secuencia: 1. Establecer el indicador de montaje que indica que el diario se está destruyendo 2. forzar una confirmación y esperarla 3. vaciar las actualizaciones pendientes del sb Esta secuencia es importante ya que garantiza que, después de este punto, no haya ninguna actualización del sb que pueda registrarse, por lo que es seguro actualizar el sb fuera del diario. (Para evitar la ejecución discutida en 2d01ddc86606) Además, no necesitamos una comprobación similar en ext4_grp_locked_error ya que solo se llama desde mballoc y AFAICT siempre sería válido programar el trabajo aquí.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nfnetlink_queue: Inicializar ctx para evitar un error de asignación de memoria. Es posible que ctx en nfqnl_build_packet_message() se utilice antes de su inicialización correcta, la cual solo se inicializa mediante nfqnl_get_sk_secctx(). Este parche corrige este problema inicializando lsmctx a un valor seguro al declararlo. Esto es similar a el commit 35fcac7a7c25 ("auditoría: Inicializar lsmctx para evitar un error de asignación de memoria").

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ax25: Eliminar el autobind roto El enlace del socket AX25 mediante la función autobind genera pérdidas de memoria en ax25_connect() y también pérdidas de recuento de referencias en ax25_release(). Se detectó una fuga de memoria con kmemleak: == ... __sys_connect (net/socket.c:2064) __x64_sys_connect (net/socket.c:2067) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) ===================================================================== Cuando se enlaza un socket, los recuentos de referencias se deben incrementar de la forma en que se hace en ax25_bind() y ax25_setsockopt() (SO_BINDTODEVICE). En caso de enlace automático, los recuentos de referencias no se incrementan. Este error provoca el siguiente problema reportado por Syzkaller: == ... ADVERTENCIA: CPU: 0 PID: 5317 en lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31 Módulos vinculados: CPU: 0 UID: 0 PID: 5317 Comm: syz-executor318 No contaminado 6.14.0-rc4-syzkaller-00278-gece144f151ac #0 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 RIP: 0010:refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31 ... Rastreo de llamadas: __refcount_dec include/linux/refcount.h:336 [en línea] refcount_dec include/linux/refcount.h:351 [en línea] ref_tracker_free+0x6af/0x7e0 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4302 [en línea] netdev_put include/linux/netdevice.h:4319 [en línea] ax25_release+0x368/0x960 net/ax25/af_ax25.c:1080 __sock_release net/socket.c:647 [en línea] sock_close+0xbc/0x240 net/socket.c:1398 __fput+0x3e9/0x9f0 fs/file_table.c:464 __do_sys_close fs/open.c:1580 [en línea] __se_sys_close fs/open.c:1565 [en línea] __x64_sys_close+0x7f/0x110 fs/open.c:1565 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 ... ===================================================================== Considerando los problemas anteriores y los comentarios que se dejaron en el código que dicen: "check Si podemos eliminar esta función, está defectuosa."; "La vinculación automática en este caso puede o no funcionar."; - Es mejor eliminar esta función por completo que corregirla, ya que está defectuosa y provoca diversos errores de memoria. Ahora, llamar a connect() sin vincular primero el socket generará un error (-EINVAL). El software de espacio de usuario que depende de la función de vinculación automática podría fallar. Sin embargo, esta función no parece ser muy utilizada con este controlador específico, ya que no era fiable en ningún momento y, de todos modos, ya está defectuosa. Por ejemplo, los paquetes ax25-tools y ax25-apps para distribuciones populares no utilizan la función de vinculación automática para AF_AX25. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_en: Enmascarar correctamente el campo bd_cnt en el TX BD El campo bd_cnt en el TX BD especifica el número total de BD para el paquete TX. El campo bd_cnt tiene 5 bits y el número máximo admitido es 32 con el valor 0. CONFIG_MAX_SKB_FRAGS se puede modificar y el número total de fragmentos SKB puede acercarse o superar el máximo admitido por el chip. Agregue una macro para enmascarar correctamente el campo bd_cnt para que el valor 32 se enmascare correctamente y se establezca en 0 en el campo bd_cnd. Sin este parche, el valor bd_cnt fuera de rango corromperá el TX BD y puede causar tiempo de espera de TX. El siguiente parche verificará los valores que excedan 32.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: error de verificación para register_netdev() en init La lógica de init actual ignora el código de error de register_netdev(), lo que provocará WARN_ON() al intentar anular su registro, si lo hubiera, y no hay información para el usuario de que falló la creación de netdev. ADVERTENCIA: CPU: 89 PID: 6902 en net/core/dev.c:11512 unregister_netdevice_many_notify+0x211/0x1a10 ... [ 3707.563641] unregister_netdev+0x1c/0x30 [ 3707.563656] idpf_vport_dealloc+0x5cf/0xce0 [idpf] [ 3707.563684] idpf_deinit_task+0xef/0x160 [idpf] [ 3707.563712] idpf_vc_core_deinit+0x84/0x320 [idpf] [ 3707.563739] idpf_remove+0xbf/0x780 [idpf] [ 3707.563769] pci_device_remove+0xab/0x1e0 [ 3707.563786] device_release_driver_internal+0x371/0x530 [ 3707.563803] driver_detach+0xbf/0x180 [ 3707.563816] bus_remove_driver+0x11b/0x2a0 [ 3707.563829] pci_unregister_driver+0x2a/0x250 Introduce una comprobación de errores y registra el número de puerto virtual y el código de error. Al eliminar, asegúrese de comprobar el indicador VPORT_REG_NETDEV antes de ejecutar las funciones unregister y free en netdev. Agregue variables locales para idx, vport_config y netdev para facilitar la lectura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrección del uso del valor no confiable de pkt_len en ice_vc_fdir_parse_raw() Se corrige el uso del valor no confiable de proto->raw.pkt_len en la función ice_vc_fdir_parse_raw() verificando que no exceda el valor VIRTCHNL_MAX_SIZE_RAW_PACKET.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btnxpuart: Se corrige el pánico del kernel durante el lanzamiento del firmware. Esto corrige un pánico del kernel observado durante el lanzamiento del firmware en un escenario de prueba de estrés donde la descarga del firmware de WLAN y Bluetooth se produce simultáneamente. Debido a un error de hardware, el chip solo envía una firma del cargador de arranque. Cuando el controlador recibe la firma del cargador de arranque, entra en modo de descarga del firmware, pero como no se detectan firmas consecutivas, no se solicita el archivo del firmware. Después de 60 segundos, cuando se agota el tiempo de descarga del firmware, release_firmware provoca un pánico del kernel. [ 2601.949184] No se puede manejar la solicitud de paginación del núcleo en la dirección virtual 0000312e6f006573 [ 2601.992076] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000111802000 [ 2601.992080] [0000312e6f006573] pgd=0000000000000000, p4d=0000000000000000 [ 2601.992087] Internal error: Oops: 0000000096000021 [#1] PREEMPT SMP [ 2601.992091] Modules linked in: algif_hash algif_skcipher af_alg btnxpuart(O) pciexxx(O) mlan(O) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce snd_soc_fsl_easrc snd_soc_fsl_asoc_card imx8_media_dev(C) snd_soc_fsl_micfil polyval_generic snd_soc_fsl_xcvr snd_soc_fsl_sai snd_soc_imx_audmux snd_soc_fsl_asrc snd_soc_imx_card snd_soc_imx_hdmi snd_soc_fsl_aud2htx snd_soc_fsl_utils imx_pcm_dma dw_hdmi_cec flexcan can_dev [ 2602.001825] CPU: 2 PID: 20060 Comm: hciconfig Tainted: G C O 6.6.23-lts-next-06236-gb586a521770e #1 [ 2602.010182] Hardware name: NXP i.MX8MPlus EVK board (DT) [ 2602.010185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2602.010191] pc : _raw_spin_lock+0x34/0x68 [ 2602.010201] lr : free_fw_priv+0x20/0xfc [ 2602.020561] sp : ffff800089363b30 [ 2602.020563] x29: ffff800089363b30 x28: ffff0000d0eb5880 x27: 0000000000000000 [ 2602.020570] x26: 0000000000000000 x25: ffff0000d728b330 x24: 0000000000000000 [ 2602.020577] x23: ffff0000dc856f38 [ 2602.033797] x22: ffff800089363b70 x21: ffff0000dc856000 [ 2602.033802] x20: ff00312e6f006573 x19: ffff0000d0d9ea80 x18: 0000000000000000 [ 2602.033809] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaad80dd480 [ 2602.083320] x14: 0000000000000000 x13: 00000000000001b9 x12: 0000000000000002 [ 2602.083326] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff800089363a30 [ 2602.083333] x8 : ffff0001793d75c0 x7 : ffff0000d6dbc400 x6 : 0000000000000000 [ 2602.083339] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000001 [ 2602.083346] x2 : 0000000000000000 x1 : 0000000000000001 x0 : ff00312e6f006573 [ 2602.083354] Call trace: [ 2602.083356] _raw_spin_lock+0x34/0x68 [ 2602.083364] release_firmware+0x48/0x6c [ 2602.083370] nxp_setup+0x3c4/0x540 [btnxpuart] [ 2602.083383] hci_dev_open_sync+0xf0/0xa34 [ 2602.083391] hci_dev_open+0xd8/0x178 [ 2602.083399] hci_sock_ioctl+0x3b0/0x590 [ 2602.083405] sock_do_ioctl+0x60/0x118 [ 2602.083413] sock_ioctl+0x2f4/0x374 [ 2602.091430] __arm64_sys_ioctl+0xac/0xf0 [ 2602.091437] invoke_syscall+0x48/0x110 [ 2602.091445] el0_svc_common.constprop.0+0xc0/0xe0 [ 2602.091452] do_el0_svc+0x1c/0x28 [ 2602.091457] el0_svc+0x40/0xe4 [ 2602.091465] el0t_64_sync_handler+0x120/0x12c [ 2602.091470] el0t_64_sync+0x190/0x194

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: libwx: corrección de la suma de comprobación L4 de transmisión. El hardware solo admite la descarga de la suma de comprobación L4 para el protocolo TCP/UDP/SCTP. Se detectó un error al configurar el indicador de suma de comprobación de transmisión para el otro protocolo, lo que provoca el bloqueo del anillo de transmisión. Se ha corregido el cálculo de la suma de comprobación de software para estos paquetes.