Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: 8250_aspeed_vuart: Se solucionó una posible desreferenciación de NULL en aspeed_vuart_probe. platform_get_resource() puede fallar y devolver NULL, por lo que deberíamos verificar mejor su valor de retorno para evitar una desreferenciación de puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-mq: no toque ->tagset en blk_mq_get_sq_hctx blk_mq_run_hw_queues() podría ejecutarse cuando no hay una solicitud en cola y después de que se limpie la cola, en ese momento se libera el conjunto de etiquetas, porque el controlador cubre la vida útil del conjunto de etiquetas y, a menudo, se libera después de que blk_cleanup_queue() regrese. Por lo tanto, no toque ->tagset para averiguar el hctx predeterminado actual por el mapeo integrado en la cola de solicitudes, por lo que se puede evitar el use-after-free en el conjunto de etiquetas. Mientras tanto, esta forma debería ser más rápida que recuperar el mapeo del conjunto de etiquetas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: comprobar la longitud del atributo para el nombre del portador syzbot informó de un valor no inicializado: ======================================================== ERROR: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:644 [inline] string+0x4f9/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283 vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50 _printk+0x18d/0x1cf kernel/printk/printk.c:2293 tipc_enable_bearer net/tipc/bearer.c:371 [inline] __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033 tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] - Do sanity check the attribute length for TIPC_NLA_BEARER_NAME. - Do not use 'illegal name' in printing message.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtc: mt6397: verificar el valor de retorno después de llamar a platform_get_resource() Causará null-ptr-deref si platform_get_resource() devuelve NULL, necesitamos verificar el valor de retorno.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: sd: Se corrige una posible desreferencia de puntero NULL Si sd_probe() detecta un error temprano antes de que se inicialice sdkp->device, se llama a sd_zbc_release_disk(). Esto provoca una desreferencia de puntero NULL cuando se llama a sd_is_zoned() dentro de esa función. Evite esto eliminando la llamada a sd_zbc_release_disk() en la ruta de error de sd_probe(). Este cambio es seguro y no da como resultado una pérdida de memoria de información de zona porque la información de zona para un disco zonificado se asigna solo cuando se llama a sd_revalidate_disk(), momento en el que sdkp->disk_dev está completamente configurado, lo que da como resultado que se llame a sd_disk_release() cuando sea necesario para limpiar la información de zona de un disco mediante sd_zbc_release_disk().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sfc: corrección considerando que todos los canales tienen colas TX Normalmente, todos los canales tienen colas RX y TX, pero esto no es cierto si se usa el modparam efx_separate_tx_channels=1. En esos casos, algunos canales solo tienen colas RX y otros solo colas TX (o más precisamente, las tienen asignadas, pero no inicializadas). Arregla efx_channel_has_tx_queues para que devuelva el valor correcto para este caso también. Mensajes mostrados en el momento de la prueba antes de la corrección: sfc 0000:03:00.0 ens6f0np0: Falló el comando MC 0x82 inlen 544 rc=-22 (raw=0) arg=0 ------------[ cortar aquí ]------------ netdevice: ens6f0np0: failed to initialise TXQ -1 WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc] [...] stripped RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc] [...] stripped Call Trace: efx_init_tx_queue+0xaa/0xf0 [sfc] efx_start_channels+0x49/0x120 [sfc] efx_start_all+0x1f8/0x430 [sfc] efx_net_open+0x5a/0xe0 [sfc] __dev_open+0xd0/0x190 __dev_change_flags+0x1b3/0x220 dev_change_flags+0x21/0x60 [...] stripped Messages shown at remove time before the fix: sfc 0000:03:00.0 ens6f0np0: failed to flush 10 queues sfc 0000:03:00.0 ens6f0np0: failed to flush queues

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: se corrige la interacción wait_for_device_probe() y deferred_probe_timeout El montaje de rootfs NFS se agotaba cuando deferred_probe_timeout no era cero [1]. Esto se debía a que la llamada de inicio ip_auto_config() agotaba el tiempo de espera a que aparecieran las interfaces de red cuando deferred_probe_timeout no era cero. Si bien ip_auto_config() llama a wait_for_device_probe() para asegurarse de que cualquier sonda diferida que se esté ejecutando actualmente funcione o la sonda asincrónica finalice, eso no era suficiente para explicar los dispositivos que se aplazaban hasta deferred_probe_timeout. El commit 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits Until the deferred_probe_timeout fires") intentó solucionar eso asegurándose de que wait_for_device_probe() espere a que deferred_probe_timeout expire antes de regresar. Sin embargo, si wait_for_device_probe() se llama desde el contexto kernel_init(): - Antes de deferred_probe_initcall() [2], hace que el proceso de arranque se cuelgue debido a un punto muerto. - Después de deferred_probe_initcall() [3], impide que kernel_init() continúe hasta que deferred_probe_timeout expire y supere el punto de deferred_probe_timeout que está tratando de esperar a que el espacio de usuario cargue módulos. Ninguna de estas opciones es buena. Por lo tanto, revierta los cambios a wait_for_device_probe(). [1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/ [2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/ [3] - https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar f2fs_bug_on() en dec_valid_node_count() Como informó Yanming en bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215897 He encontrado un error en el sistema de archivos F2FS en el kernel v5.17. El kernel debería habilitar CONFIG_KASAN=y y CONFIG_KASAN_INLINE=y. Puede reproducir el error ejecutando los siguientes comandos: El mensaje del kernel se muestra a continuación: kernel BUG at fs/f2fs/f2fs.h:2511! Call Trace: f2fs_remove_inode_page+0x2a2/0x830 f2fs_evict_inode+0x9b7/0x1510 evict+0x282/0x4e0 do_unlinkat+0x33a/0x540 __x64_sys_unlinkat+0x8e/0xd0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is: .total_valid_block_count or .total_valid_node_count could fuzzed to zero, then once dec_valid_node_count() was called, it will cause BUG_ON(), este parche corrige la impresión de información de advertencia y la configuración de SBI_NEED_FSCK en CP en lugar de pánico.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jffs2: se corrige la pérdida de memoria en jffs2_do_fill_super Si jffs2_iget() o d_make_root() en jffs2_do_fill_super() devuelve un error, podemos observar el siguiente informe de kmemleak: -------------------------------------------- objeto sin referencia 0xffff888105a65340 (size 64): comm "mount", pid 710, jiffies 4302851558 (age 58.239s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmem_cache_alloc_trace+0x475/0x8a0 [] jffs2_sum_init+0x96/0x1a0 [] jffs2_do_mount_fs+0x745/0x2120 [] jffs2_do_fill_super+0x35c/0x810 [] jffs2_fill_super+0x2b9/0x3b0 [...] unreferenced object 0xffff8881bd7f0000 (size 65536): comm "mount", pid 710, jiffies 4302851558 (age 58.239s) hex dump (first 32 bytes): bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ backtrace: [] kmalloc_order+0xda/0x110 [] kmalloc_order_trace+0x21/0x130 [] __kmalloc+0x711/0x8a0 [] jffs2_sum_init+0xd9/0x1a0 [] jffs2_do_mount_fs+0x745/0x2120 [] jffs2_do_fill_super+0x35c/0x810 [] jffs2_fill_super+0x2b9/0x3b0 [...] -------------------------------------------- Esto se debe a que los recursos asignados en jffs2_sum_init() no se liberan. Llame a jffs2_sum_exit() para liberar estos recursos y resolver el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: watchdog: rzg2l_wdt: Fix 'BUG: Invalid wait context' Este parche corrige el problema 'BUG: Invalid wait context' durante la devolución de llamada restart() al usar clk_prepare_enable() en lugar de pm_runtime_get_sync() para encender los relojes durante el reinicio. Este problema se detecta al realizar pruebas con renesas_defconfig. [ 42.213802] reiniciar: Reiniciando el sistema [ 42.217860] [ 42.219364] ============================== [ 42.223368] [ BUG: Invalid wait context ] [ 42.227372] 5.17.0-rc5-arm64-renesas-00002-g10393723e35e #522 Not tainted [ 42.234153] ----------------------------- [ 42.238155] systemd-shutdow/1 is trying to lock: [ 42.242766] ffff00000a650828 (&genpd->mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x14/0x20 [ 42.250709] other info that might help us debug this: [ 42.255753] context-{4:4} [ 42.258368] 2 locks held by systemd-shutdow/1: [ 42.262806] #0: ffff80000944e1c8 (system_transition_mutex#2){+.+.}-{3:3}, at: __do_sys_reboot+0xd0/0x250 [ 42.272388] #1: ffff8000094c4e40 (rcu_read_lock){....}-{1:2}, at: atomic_notifier_call_chain+0x0/0x150 [ 42.281795] stack backtrace: [ 42.284672] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.17.0-rc5-arm64-renesas-00002-g10393723e35e #522 [ 42.294577] Hardware name: Renesas SMARC EVK based on r9a07g044c2 (DT) [ 42.301096] Call trace: [ 42.303538] dump_backtrace+0xcc/0xd8 [ 42.307203] show_stack+0x14/0x30 [ 42.310517] dump_stack_lvl+0x88/0xb0 [ 42.314180] dump_stack+0x14/0x2c [ 42.317492] __lock_acquire+0x1b24/0x1b50 [ 42.321502] lock_acquire+0x120/0x3a8 [ 42.325162] __mutex_lock+0x84/0x8f8 [ 42.328737] mutex_lock_nested+0x30/0x58 [ 42.332658] genpd_lock_mtx+0x14/0x20 [ 42.336319] genpd_runtime_resume+0xc4/0x228 [ 42.340587] __rpm_callback+0x44/0x170 [ 42.344337] rpm_callback+0x64/0x70 [ 42.347824] rpm_resume+0x4e0/0x6b8 [ 42.351310] __pm_runtime_resume+0x50/0x78 [ 42.355404] rzg2l_wdt_restart+0x28/0x68 [ 42.359329] watchdog_restart_notifier+0x1c/0x30 [ 42.363943] atomic_notifier_call_chain+0x94/0x150 [ 42.368732] do_kernel_restart+0x24/0x30 [ 42.372652] machine_restart+0x44/0x70 [ 42.376399] kernel_restart+0x3c/0x60 [ 42.380058] __do_sys_reboot+0x228/0x250 [ 42.383977] __arm64_sys_reboot+0x20/0x28 [ 42.387983] invoke_syscall+0x40/0xf8

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: rockchip: Se ha corregido la pérdida de recuento de referencias en rockchip_grf_init. of_find_matching_node_and_match devuelve un puntero de nodo con el recuento de referencias incrementado. Deberíamos usar of_node_put() en él cuando haya terminado. Se ha añadido el error of_node_put() que falta para evitar la pérdida de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para borrar el inodo sucio en f2fs_evict_inode() Como informó Yanming en Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215904 El mensaje del kernel se muestra a continuación: ¡ERROR del kernel en fs/f2fs/inode.c:825! Call Trace: evict+0x282/0x4e0 __dentry_kill+0x2b2/0x4d0 shrink_dentry_list+0x17c/0x4f0 shrink_dcache_parent+0x143/0x1e0 do_one_tree+0x9/0x30 shrink_dcache_for_umount+0x51/0x120 generic_shutdown_super+0x5c/0x3a0 kill_block_super+0x90/0xd0 kill_f2fs_super+0x225/0x310 deactivate_locked_super+0x78/0xc0 cleanup_mnt+0x2b7/0x480 task_work_run+0xc8/0x150 exit_to_user_mode_prepare+0x14a/0x150 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 The root cause is: inode node and dnode node share the same nid, so during f2fs_evict_inode(), dnode node truncation will invalidate its NAT entry, so when truncating inode node, it fails due to invalid NAT entry, result in inode is still marked as dirty, fix this issue by clearing dirty for inode and setting SBI_NEED_FSCK flag in filesystem. output from dump.f2fs: [print_node_info: 354] Node ID [0xf:15] is inode i_nid[0] [0x f : 15]