Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: inet_diag: inicializa el campo pad en la estructura inet_diag_req_v2 KMSAN informó acceso de valor uninit en raw_lookup() [1]. Diag para sockets sin formato utiliza el campo pad en struct inet_diag_req_v2 para el protocolo subyacente. Este campo corresponde al campo sdiag_raw_protocol en la estructura inet_diag_req_raw. inet_diag_get_exact_compat() convierte inet_diag_req en inet_diag_req_v2, pero deja el campo pad sin inicializar. Entonces el problema ocurre cuando raw_lookup() accede al campo sdiag_raw_protocol. Solucione este problema inicializando el campo pad en inet_diag_get_exact_compat(). Además, haga la misma corrección en inet_diag_dump_compat() para evitar problemas similares en el futuro. [1] ERROR: KMSAN: valor uninit en raw_lookup net/ipv4/raw_diag.c:49 [en línea] ERROR: KMSAN: valor uninit en raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4 /raw_diag.c:49 [en línea] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/ inet_diag.c :1404 [en línea] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670. c:2564 sock_diag_rcv+0x35 /0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [en línea] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c :1905 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket. c:2639 __sys_sendmsg net/socket.c:2668 [en línea] __do_sys_sendmsg net/socket.c:2677 [en línea] __se_sys_sendmsg net/socket.c:2675 [en línea] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x13 5e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit se almacenó en la memoria en: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag .c:1404 [en línea] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:256 4 calcetín_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [en línea] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:263 9 __sys_sendmsg neto/ socket.c:2668 [en línea] __do_sys_sendmsg net/socket.c:2677 [en línea] __se_sys_sendmsg net/socket.c:2675 [en línea] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/ 0x3ce0 arch/x86 /include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f Variable local req.i creado en: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [en línea] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c: 282 procesadores: 1 PID: 8888 Comm: syz-executor.6 No contaminado 6.10.0-rc4-00217-g35bb670d65fc #32 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 01/04/2014

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: vaciar incondicionalmente el trabajo pendiente antes de que el notificador syzbot informe: KASAN: slab-uaf en nft_ctx_update include/net/netfilter/nf_tables.h:1831 KASAN: slab-uaf en nft_commit_release net/netfilter/nf_tables_api.c:9530 KASAN: slab-uaf int nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597 Lectura de tamaño 2 en la dirección ffff88802b0051c4 por tarea kworker/1:1/45 [..] ue : eventos nf_tables_trans_destroy_work Seguimiento de llamadas: nft_ctx_update include/net/netfilter/nf_tables.h:1831 [en línea] nft_commit_release net/netfilter/nf_tables_api.c:9530 [en línea] nf_tables_trans_destroy_work+0x152b/0x1750 s_api.c:9597 El problema es que el notificador realiza un vaciado condicional, pero es posible que las transacciones que procesa el trabajador aún hagan referencia a la tabla que se va a eliminar, por lo que debemos realizar un vaciado incondicional. Podríamos hacer que flux_work dependa de si encontramos una tabla para eliminar en nf-next para evitar el vaciado en la mayoría de los casos. AFAICS, este problema solo se expone en nf-next, con la confirmación e169285f8c56 ("netfilter: nf_tables: no almacenar nft_ctx en objetos de transacción"), con esta confirmación aplicada hay una búsqueda incondicional de tabla->familia que es lo que desencadena lo anterior salpicar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ntb_netdev: Mover ntb_netdev_rx_handler() para llamar a netif_rx() desde __netif_rx() Lo siguiente se emite cuando se utiliza idxd (DSA) dmanegine como transportador de datos para ntb_transport que utiliza ntb_netdev. [74412.546922] ERROR: usar smp_processor_id() en código interrumpible [00000000]: irq/52-idxd-por/14526 [74412.556784] la persona que llama es netif_rx_internal+0x42/0x130 [74412.562282] CPU: 6 PID: 6 Comunicaciones: irq/52- idxd-por No contaminado 6.9.5 #5 [74412.569870] Nombre de hardware: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 08/02/2024 [74412.581699] Seguimiento de llamadas: [74412.584514] [ 74412.586933] dump_stack_lvl+0x55/0x70 [74412.591129] check_preemption_disabled+0xc8/0xf0 [74412.596374] netif_rx_internal+0x42/0x130 [74412.600957] 0/0xd0 [74412.604743] ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev] [74412.610985] ntb_complete_rxc+0xed/0x140 [ntb_transport] [74412.617010] ntb_rx_copy_callback+0x53/0x80 [ntb_transport] [74412.623332] idxd_dma_complete_txd+0xe3/0x160 [idxd] [74412.628963] idxd_wq_thread+0x1a6/0x 2b0 [idxd] [74412.634046] irq_thread_fn+0x21/0x60 [74412.638134] ? hilo_irq+0xa8/0x290 [74412.642218] hilo_irq+0x1a0/0x290 [74412.646212] ? __pfx_irq_thread_fn+0x10/0x10 [74412.651071] ? __pfx_irq_thread_dtor+0x10/0x10 [74412.656117] ? __pfx_irq_thread+0x10/0x10 [74412.660686] kthread+0x100/0x130 [74412.664384] ? __pfx_kthread+0x10/0x10 [74412.668639] ret_from_fork+0x31/0x50 [74412.672716] ? __pfx_kthread+0x10/0x10 [74412.676978] ret_from_fork_asm+0x1a/0x30 [74412.681457] La causa se debe a que el controlador de finalización de interrupciones del controlador idxd utiliza interrupciones de subprocesos y el controlador de subprocesos no es un contexto de interrupción dura o suave. Sin embargo, __netif_rx() solo se puede llamar desde el contexto de interrupción. Cambie la llamada a netif_rx() para permitir la finalización a través del contexto normal para los controladores dmaengine que utilizan el manejo de irq por subprocesos. Si bien la siguiente confirmación cambió de netif_rx() a __netif_rx(), baebdf48c360 ("net: dev: se asegura de que netif_rx() pueda invocarse en cualquier contexto."), el cambio debería haber sido un fracaso. Sin embargo, el código que precede a esta solución debería haber usado netif_rx_ni() o netif_rx_any_context().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: restringir los valores de NL80211_ATTR_TXQ_QUANTUM syzbot puede activar bloqueos suaves, configurando NL80211_ATTR_TXQ_QUANTUM en 2^31. Tuvimos un problema similar en sch_fq, solucionado con la confirmación d9e15a273306 ("pkt_sched: fq: no acepte el tonto TCA_FQ_QUANTUM") guardián: ERROR: bloqueo suave - ¡CPU#1 bloqueada durante 26 segundos! [kworker/1:0:24] Módulos vinculados en: irq event stamp: 131135 hardirqs habilitados por última vez en (131134): [] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last habilitado en (131134): [] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs deshabilitado por última vez en (131135): [] __el1_irq arch/arm64/kernel/entry -common.c:533 [inline] hardirqs deshabilitado por última vez en (131135): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs habilitado por última vez en (125892): [< ffff80008907e82c>] neigh_hh_init net/core/neighbour.c:1538 [en línea] softirqs habilitado por última vez en (125892): [] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553 softirqs deshabilitado por última vez en (12589 6) : [] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19 CPU: 1 PID: 24 Comm: kworker/1:0 No contaminado 6.9.0-rc7-syzkaller-gfda5695d692c #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 Cola de trabajo: mld mld_ifc_work pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: __list_del include/linux/list.h :195 [en línea] pc: __list_del_entry include/linux/list.h:218 [en línea] pc: list_move_tail include/linux/list.h:310 [en línea] pc: fq_tin_dequeue include/net/fq_impl.h:112 [en línea] pc: ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr: __list_del_entry include/linux/list.h:218 [en línea] lr: list_move_tail include/linux/list.h:310 [en línea] lr: fq_tin_dequeue incluye /net/fq_impl.h:112 [en línea] lr: ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854 sp: ffff800093d36700 x29: ffff800093d36a60 x28: ffff800093d36960 27: dfff800000000000 x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0 x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0 x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0 x17: 00000000000 0d476 x16: ffff8000805519dc x15: ffff7000127a6cc8 x14: 1ffff000127a6cc8 x13: 00000000000000004 x12: ffffffffffffffff x11: ffff7000127a6cc8 x10: 000ff0100 x9: 0000000000000000 x8: 0000000000000000 x7: 0000000000000000 x6 : 0000000000000000 x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0 032470 Seguimiento de llamadas: __list_del include/linux/list.h:195 [en línea] __list_del_entry include/linux/list.h:218 [en línea] list_move_tail include/linux/list.h:310 [en línea] fq_tin_dequeue include/net/fq_impl.h:112 [en línea] ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 wake_tx_push_queue net/mac80211/util.c:294 [ en línea] ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [en línea] Schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [en línea] ieee80211_queue_skb+0x18e8/ 0x2244 net/mac80211/tx.c:1664 ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062 __ieee80211_subif_start_x mit+0xab8/0x122c net/mac80211/tx.c :4338 ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532 __netdev_start_xmit include/linux/netdevice.h:4903 [en línea] netdev_start_xmit include/linux/netdevice.h:4917 [en línea] xmit_one net/core/dev.c :3531 [en línea] dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547 __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [en línea] neigh_resolve_output+0x558/ 0x658---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: jffs2: corrija el posible acceso ilegal a la dirección en jffs2_free_inode Durante la prueba de esfuerzo del sistema de archivos jffs2, se encontraron las siguientes impresiones anormales: [2430.649000] No se puede manejar la solicitud de paginación del kernel en la dirección virtual 0069696969696948 [ 2430.649622] Información de cancelación de memoria: [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (EL actual), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.651032] FSC = 0x04: error de traducción de nivel 0 [ 2430.651446] Información de cancelación de datos: [ 2430.651683] ISV = 0, ISS = 0x00000004 [ 2430.652001] CM = 0, WnR = 0 [ 2430.652558] [0069696969696948] dirección entre usuario y kernel rangos de direcciones [2430.653265] Error interno: Ups: 96000004 [#1] PREEMPT SMP [2430.654512] CPU: 2 PID: 20919 Comm: cat No contaminado 5.15.25-g512f31242bf6 #33 [2430.655008] Nombre de hardware: tonto-virt ( DT) [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2430.656142] pc : kfree+0x78/0x348 [ 2430.656630] lr : jffs2_free_inode+0x24/0x48 [ 2430.657051]sp : ffff800009eebd10 [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000 [ 2430.658327] x26: ffff000038f09d80 25: 0080000000000000 x24: ffff800009d38000 [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14 [ 2430.65943 4] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 00000000000000000 [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000 [ 2430.660637] x14: 0000000000000000 x13: 00000001000 820a1 x12: 00000000000d1b19 [2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9: ffff8000084f0d14 [2430.662025] x8: bf9a6b40 x7: ffff0000bf9a6b48 x6: 0000000003470302 [2430.662695 ] x5: ffff00002e41dcc0 x4: ffff0000bf9aa3b0 x3: 0000000003470342 [2430.663486] x2: 0000000000000000 x1: ffff8000084f0d14 x0: ffffc0000000 000 [2430.664217] Rastreo de llamadas: [2430.664528] kfree+0x78/0x348 [2430.664855] jffs2_free_inode+0x24/0x48 [2430.665233] i_callback+0x24 /0x50 [ 2430.665528] rcu_do_batch+0x1ac/0x448 [ 2430.665892] rcu_core+0x28c/0x3c8 [ 2430.666151] rcu_core_si+0x18/0x28 [ 2430.666473] x138/0x3cc [ 2430.666781] irq_exit+0xf0/0x110 [ 2430.667065] handle_domain_irq+0x6c/0x98 [ 2430.667447] gic_handle_irq+0xac/0xe8 [ 2430.667739] call_on_irq_stack+0x28/0x54 El parámetro pasado a kfree fue 5a5a5a5a, que corresponde al campo de destino de la estructura jffs_inode_info. Se encontró que todas las variables en la estructura jffs_inode_info eran 5a5a5a5a, excepto el primer miembro sem. Se sospecha que estas variables no se inicializan porque se configuraron en 5a5a5a5a durante la prueba de memoria, lo que pretende detectar memoria no inicializada. La variable sem se inicializa en la función jffs2_i_init_once, mientras que otros miembros se inicializan en la función jffs2_init_inode_info. La función jffs2_init_inode_info se llama después de iget_locked, pero en la función iget_locked, se activa el proceso destroy_inode, que libera el inodo y, en consecuencia, el miembro objetivo del inodo no se inicializa. En escenarios concurrentes de alta presión, iget_locked puede ingresar a la rama destroy_inode como descrito en el código. Dado que la funcionalidad destroy_inode de jffs2 solo libera el objetivo, el método de reparación es establecer el objetivo en NULL en jffs2_i_init_once.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mediatek: vcodec: Solo libera el búfer VA que no es NULL En el controlador MediaTek vcodec, mientras que mtk_vcodec_mem_free() se llama principalmente solo cuando el búfer a liberar existe, hay algunas casos que no hicieron la verificación y activaron advertencias en la práctica. Creemos que esos cheques se olvidaron sin querer. Vuelva a agregar las comprobaciones para corregir las advertencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/dasd: corrige la desreferenciación no válida del puntero de datos CCW indirecto. Se corrige la desreferenciación no válida del puntero de datos CCW indirecto en dasd_eckd_dump_sense() que genera pánico en el kernel en casos de error. Cuando se utiliza direccionamiento indirecto para DASD CCW (IDAW), el puntero CCW CDA no contiene la dirección de datos en sí, sino un puntero al IDAL. Esto también debe traducirse de físico a virtual antes de usarlo. Esta desreferenciación también se usa para dasd_page_cache y también se corrige, aunque es muy poco probable que esta ruta de código se use alguna vez.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: sunxi-ng: common: no llame a hw_to_ccu_common en hw sin common Para establecer el rango de velocidad de un hw, sunxi_ccu_probe llama a hw_to_ccu_common() asumiendo todas las entradas en desc- >ccu_clks están contenidos en una estructura ccu_common. Esta suposición es incorrecta y, en consecuencia, provoca desreferencias de punteros no válidas. Eliminar la llamada defectuosa. En su lugar, agregue un bucle más que itere sobre ccu_clks y establezca el rango de velocidad, si es necesario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau: corrige la desreferencia del puntero null en nouveau_connector_get_modes En nouveau_connector_get_modes(), el valor de retorno de drm_mode_duplicate() se asigna al modo, lo que conducirá a una posible desreferencia del puntero NULL en caso de fallo. de drm_mode_duplicate(). Agregue una marca para evitar npd.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "mm/writeback: corrige la posible división por cero en wb_dirty_limits(), nuevamente" Patch series "mm: evita posibles desbordamientos en la aceleración sucia". La lógica de limitación sucia supone que los límites sucios en las unidades de páginas caben en 32 bits. Esta serie de parches garantiza que esto sea cierto (consulte el parche 2/2 para obtener más detalles). Este parche (de 2): esto revierte la confirmación 9319b647902cbd5cc884ac08a8a6d54ce111fc78. El compromiso se rompe de varias maneras. En primer lugar, la conversión eliminada (u64) de la multiplicación introducirá un desbordamiento de multiplicación en arcos de 32 bits si wb_thresh * bg_thresh >= 1<<32 (lo cual es realmente común; la configuración predeterminada con 4 GB de RAM activará esto). En segundo lugar, div64_u64() es innecesariamente caro en arcos de 32 bits. Tenemos div64_ul() en caso de que queramos ser seguros y económicos. En tercer lugar, si los umbrales sucios son mayores que 1<<32 páginas, entonces el equilibrio sucio explotará de muchas otras maneras espectaculares de todos modos, por lo que intentar solucionar un posible desbordamiento es discutible.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige la adición de un grupo de bloques a una lista de recuperación y la lista no utilizada durante la recuperación. Existe una posible adición de lista paralela para volver a intentarlo en btrfs_reclaim_bgs_work y agregarla a la lista no utilizada. Dado que el grupo de bloques se elimina de la lista de recuperación y se encuentra en un trabajo de reubicación, se puede agregar a la lista no utilizada en paralelo. Cuando eso sucede, agregarlo a la lista de recuperación dañará el encabezado de la lista y provocará una corrupción en la lista como se muestra a continuación. Solucionarlo tomando fs_info->unused_bgs_lock. [177.504][T2585409] Error BTRFS (dispositivo nullb1): error al reubicar ch= unk 2415919104 [177.514][T2585409] corrupción list_del. siguiente->anterior debería ser ff1100= 0344b119c0, pero era ff11000377e87c70. (next=3Dff110002390cd9c0) [177.529][T2585409] ------------[ cortar aquí ]------------ [177.537][T2585409] ERROR del kernel en lib/ list_debug.c:65! [177.545][T2585409] Ups: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN NOPTI [177.555][T2585409] CPU: 9 PID: 2585409 Comm: kworker/u128:2 Contaminado: GW 6.10.0-rc5-kts # 1 [177.568][T2585409] Nombre de hardware: Supermicro SYS-520P-WTR/X12SPW-TF, BIOS 1.2 14/02/2022 [177.579][T2585409] Cola de trabajo: events_unbound btrfs_reclaim_bgs_work[btrfs] [177.589][T2585409] QEPD: 0010 :__list_del_entry_valid_or_report.cold+0x70/0x72 [177.624][T2585409] RSP: 0018:ff11000377e87a70 EFLAGS: 00010286 [177.633][T2585409] RAX: 000000000000006d RBX: ff11000344b119c0 RCX:0000000000000000 [177.644][T2585409] RDX: 000000000000006d RSI: 0000000000000008 RDI :ffe21c006efd0f40 [177.655][T2585409] RBP: ff110002e0509f78 R08: 0000000000000001 R09:ffe21c006efd0f08 [177.665][T2585409] R10: 7847 R11: 0000000000000000 R12:ff110002390cd9c0 [177.676][T2585409] R13: ff11000344b119c0 R14: ff110002e0508000 R15:dffffc0000000000 [177. 687] [T2585409] FS: 0000000000000000(0000) GS:ff11000fec880000(0000) knlGS:0000000000000000 [177.700][T2585409] CS: 0010 DS: 0000 ES: 0000 CR0: 00000080050033 [177.709][T2585409] CR2: 00007f06bc7b1978 CR3: 0000001021e86005 CR4: 0000000000771ef0 [177.720][T2585409] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000 [177.731][T2585409] DR3: 00000000 DR6: 00000000fffe0ff0 DR7:0000000000000400 [177.742][T2585409] PKRU: 55555554 [177.748][T2585409] Seguimiento de llamadas: [ 177.753][T2585409] [177.759][T2585409] ? __die_body.cold+0x19/0x27 [177.766][T2585409] ? morir+0x2e/0x50 [177.772][T2585409] ? do_trap+0x1ea/0x2d0 [177.779][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.788][T2585409] ? do_error_trap+0xa3/0x160 [177.795][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.805][T2585409] ? handle_invalid_op+0x2c/0x40 [177.812][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.820][T2585409] ? exc_invalid_op+0x2d/0x40 [177.827][T2585409] ? asm_exc_invalid_op+0x1a/0x20 [177.834][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.843][T2585409] btrfs_delete_unused_bgs+0x3d9/0x14c0 [btrfs] Hay un código retry_list similar en btrfs_delete_unused_bgs(), pero es seguro, AFAICS. Dado que el grupo de bloques estaba en la lista no utilizada, los bytes usados deberían ser 0 cuando se agregó a la lista no utilizada. Luego, verifica que block_group->{used,reserved,pinned} todavía sean 0 bajo block_group->lock. Por lo tanto, aún deberían ser elegibles para la lista no utilizada, no para la lista de recuperación. La razón por la que es seguro allí es porque mantenemos space_info->groups_sem en modo de escritura. Eso significa que ninguna otra tarea puede asignar desde el grupo de bloques, por lo que mientras estamos en deleted_unused_bgs() no es posible que otras tareas asignen y desasignen extensiones del grupo de bloques, por lo que no se pueden agregar a la lista no utilizada ni a la reclamación. lista por cualquier otra persona. El error puede repro ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: agrega una verificación faltante para los números de inodo en las entradas del directorio Syzbot informó que montar y desmontar un patrón específico de imágenes corruptas del sistema de archivos nilfs2 provoca un use after free de los inodos del archivo de metadatos, lo que desencadena un error del kernel en lru_add_fn(). Como señaló Jan Kara, esto se debe a que el recuento de enlaces de un archivo de metadatos se corrompe a 0, y nilfs_evict_inode(), que se llama desde iput(), intenta eliminar ese inodo (inodo ifile en este caso). La inconsistencia se produce porque los directorios que contienen los números de inodo de estos archivos de metadatos que no deberían ser visibles en el espacio de nombres se leen sin verificar. Solucione este problema tratando los números de inodo de estos archivos internos como errores en el asistente de verificación de cordura al leer folios/páginas del directorio. También gracias a Hillf Danton y Matthew Wilcox por su análisis inicial de capas mm.