Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: check skb is non-NULL in tcp_rto_delta_us() Tenemos algunas máquinas que ejecutan Ubuntu 20.04.6 de fábrica, que es su kernel 5.4.0-174-generic, que ejecutan ceph y recientemente encontraron una desreferencia ptr nula en tcp_rearm_rto(). Inicialmente, lo encontramos desde la ruta TLP, pero luego también lo encontramos desde el caso RACK. Estos son ejemplos de los mensajes de error que vimos en cada uno de esos casos: Jul 26 15:05:02 rx [11061395.780353] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: acceso de lectura de supervisor en modo kernel Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - página no presente Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI 26 de julio 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Contaminado: GW 5.4.0-174-generic #193-Ubuntu 26 de julio 15:05:02 rx [11061395.814996] Nombre del hardware: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 09/05/2023 26 de julio 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 26 de julio 15:05:02 rx [11061395.830656] Código: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 26 jul 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 26 jul 15:05:02 rx [11061395.855149] RAX: 000000000000000 RBX: 20c49ba5e353f7cf RCX: 000000000000000 26 jul 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 26 de julio 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 26 de julio 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 26 de julio 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 26 de julio 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 26 de julio 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 26 de julio 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 26 de julio 15:05:02 rx [11061395.913822] PKRU: 55555554 26 de julio 15:05:02 rx [11061395.916786] Rastreo de llamadas: 26 de julio 15:05:02 rx [11061395.919488] 26 de julio 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f 26 de julio 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 26 de julio 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 26 de julio 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 26 de julio 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 26 de julio 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 26 de julio 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 26 de julio 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 26 de julio 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 26 de julio 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 26 de julio 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 26 de julio 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 26 de julio 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 26 de julio 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 26 de julio 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 26 de julio 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 26 de julio 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 26 de julio 15:05:02 rx [11061395.994814] ? recalibrate_cpu_khz+0x10/0x10 26 de julio 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 26 de julio 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() La matriz psc->div[] tiene elementos psc->num_div. Estos valores provienen de cuando llamamos a clk_hw_register_div(). Son adc_divisors y ARRAY_SIZE(adc_divisors)) y así sucesivamente. Por lo tanto, esta condición debe ser >= en lugar de > para evitar una lectura fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: deshacerse de la reparación en línea en un directorio dañado syzbot informa un error de f2fs como el siguiente: ¡ERROR del kernel en fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Seguimiento de llamadas: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [en línea] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [en línea] ptrace_report_syscall_exit include/linux/ptrace.h:477 [en línea] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_salir_a_modo_usuario_prepare kernel/entry/common.c:200 [en línea] __syscall_salir_a_modo_usuario_work kernel/entry/common.c:205 [en línea] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 La reparación en línea en un directorio dañado en f2fs_lookup() puede generar datos/meta sucios mientras se corre con el remontaje de solo lectura, puede dejar un inodo sucio después de que el sistema de archivos se vuelva de solo lectura, sin embargo, checkpoint() omitirá la limpieza del inodo sucio en un estado de modo de solo lectura, lo que dará como resultado el pánico mencionado anteriormente. Deshagámonos de la reparación en línea en f2fs_lookup() y dejemos el trabajo a fsck.f2fs.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: devuelve -EINVAL cuando namelen es 0 Cuando tenemos un main.sqlite dañado en /var/lib/nfs/nfsdcld/, puede resultar en que namelen sea 0, lo que hará que memdup_user() devuelva ZERO_SIZE_PTR. Cuando accedemos al name.data al que se le ha asignado el valor ZERO_SIZE_PTR en nfs4_client_to_reclaim(), se activa la desreferencia de puntero nulo. [ T1205] ========================================================================= [ T1205] ERROR: KASAN: null-ptr-deref en nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Lectura de tamaño 1 en la dirección 0000000000000010 por la tarea nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld No contaminado 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware nombre: PC estándar QEMU (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 01/04/2014 [ T1205] Seguimiento de llamadas: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Código: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 000000000000000 R09: 00000000000000001 [ T1205] R10: 00000000000000000 R11: 00000000000000246 R12: 0000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ========================================================================= Arréglelo comprobando namelen.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Omitir recálculo de parámetros DSC si no hay flujo en el enlace [por qué] Se encuentra una desreferencia de puntero NULL en la configuración de mst + dsc. ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway No contaminado 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Nombre del hardware: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 28/07/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Código: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 00000000000000224 RDX: ffff8afb9ee37c00 RSI: RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Seguimiento de llamadas: ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? plist_add+0xbe/0x100 ? exc_page_fault+0x7c/0x180 ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] configuración_mst_dsc_compute_para_enlace+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] ? atributos de búfer de plano de relleno+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] configuraciones de cálculo mst_dsc para estado+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] solo comprobación atómica drm+0x5c5/0xa40 drm_mode_atomic_ioctl+0x76e/0xbc0 [cómo] Se debe omitir el recálculo de dsc si no se detecta ningún cambio de modo en la nueva solicitud. Si se detecta, se debe seguir verificando si la transmisión ya está en el estado actual o no.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_reject_ipv6: corrección de nf_reject_ip6_tcphdr_put() syzbot informó que nf_reject_ip6_tcphdr_put() posiblemente estaba enviando basura en los cuatro bits tcp reservados (th->res1) Utilice skb_put_zero() para borrar todo el encabezado TCP, como se hace en nf_reject_ip_tcphdr_put() ERROR: KMSAN: valor no inicializado en nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 evaluación_operaciones_llamada_expr net/netfilter/nf_tables_core.c:240 [en línea] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn incluye/linux/netfilter.h:154 [en línea] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook incluye/linux/netfilter.h:269 [en línea] NF_HOOK incluye/linux/netfilter.h:312 [en línea] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [en línea] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [en línea] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [en línea] rcu_read_unlock_bh incluir/linux/rcupdate.h:908 [en línea] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit incluir/linux/netdevice.h:3105 [en línea] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output incluir/net/neighbour.h:542 [en línea] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [en línea] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND incluye/linux/netfilter.h:303 [en línea] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output incluye/net/dst.h:450 [en línea] NF_HOOK incluye/linux/netfilter.h:314 [en línea] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [en línea] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [en línea] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [en línea] __se_sys_connect net/socket.c:2085 [en línea] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit se almacenó en la memoria en: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 evaluación_operaciones_llamada_expr net/netfilter/nf_tables_core.c:240 [en línea] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn incluye/linux/netfilter.h:154 [en línea] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook incluye/linux/netfilter.h:269 [en línea] NF_HOOK incluye/linux/netfilter.h:312 [en línea] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige el use after free en bpf_uprobe_multi_link_attach() Si bpf_link_prime() fallo, bpf_uprobe_multi_link_attach() va a la etiqueta error_free y libera la matriz de bpf_uprobe sin llamar a bpf_uprobe_unregister(). Esto filtra bpf_uprobe->uprobe y, lo que es peor, libera bpf_uprobe->consumer sin eliminarlo de la lista uprobe->consumers.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb.c: corrección del UAF de vma en la ruta de error hugetlb Syzbot informa un UAF en hugetlb_fault(). Esto sucede porque vmf_anon_prepare() podría eliminar el bloqueo por VMA y permitir que se libere el VMA actual antes de que se llame a hugetlb_vma_unlock_read(). Podemos solucionar esto utilizando una versión modificada de vmf_anon_prepare() que no libere el bloqueo de VMA en caso de error y luego lo liberemos nosotros mismos después de hugetlb_vma_unlock_read().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: resuelve la pérdida de memoria de exfat_create_upcase_table() Si exfat_load_upcase_table llega al final y devuelve -EINVAL, la memoria asignada no se libera y mientras exfat_load_default_upcase_table asigna más memoria, lo que provoca una pérdida de memoria. Aquí hay un enlace al informe de fallos de syzkaller que ilustra este problema: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: icmp: cambia el orden de los límites de velocidad Los mensajes ICMP están limitados por velocidad: después de las confirmaciones culpables, se aplican los dos limitadores de velocidad en este orden: 1) límite de velocidad de todo el host (icmp_global_allow()) 2) límite de velocidad por destino (basado en inetpeer) Para evitar ataques de canales secundarios, primero debemos aplicar la comprobación por destino. Este parche realiza el siguiente cambio: 1) icmp_global_allow() comprueba si se ha alcanzado el límite de todo el host. Pero aún no se han consumido los créditos. Esto se pospone a 3) 2) Se comprueba/actualiza el límite por destino. Esto podría agregar un nuevo nodo en el árbol inetpeer. 3) icmp_global_consume() consume tokens si las operaciones anteriores tuvieron éxito. Esto significa que el límite de velocidad de todo el host sigue siendo eficaz para mantener pequeño el árbol inetpeer incluso bajo DDOS. Como beneficio adicional, eliminé icmp_global.lock ya que la ruta rápida puede usar una operación sin bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfs: arregla la ejecución entre evice_inodes() y find_inode()&iput() Hola a todos Recientemente noté un error[1] en btrfs, después de investigarlo y creo que es una ejecución en vfs. Supongamos que hay un inodo (es decir, ino 261) con i_count 1 que es llamado por iput(), y hay un hilo concurrente que llama a generic_shutdown_super(). cpu0: cpu1: iput() // i_count es 1 ->spin_lock(inode) ->dec i_count a 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // por alguna razón[2] ->if (atomic_read(inode->i_count)) continue; // regresar antes // el inodo 261 pasó la verificación anterior // list_lru_add_obj() // y luego programar la salida ->spin_unlock() // nota aquí: el inodo 261 // todavía estaba en la lista sb y la lista hash, // y I_FREEING|I_WILL_FREE no se había establecido btrfs_iget() // después de algunas llamadas de función ->find_inode() // encontró el inodo 261 anterior ->spin_lock(inode) // verificó I_FREEING|I_WILL_FREE // y pasó ->__iget() ->spin_unlock(inode) // programó de regreso ->spin_lock(inode) // verificó los indicadores (I_NEW|I_FREEING|I_WILL_FREE), // pasó y estableció I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count a 0 ->iput_final() ->spin_unlock() ->evict() Ahora, tenemos dos subprocesos expulsando simultáneamente el mismo inodo, lo que puede activar la declaración BUG(inode->i_state & I_CLEAR) tanto dentro de clear_inode() como de iput(). Para corregir el error, vuelva a verificar inode->i_count después de mantener i_lock. Porque en la mayoría de los escenarios, la primera verificación es válida y se puede reducir la sobrecarga de spin_lock(). Si hay algún malentendido, hágamelo saber, gracias. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: La razón podría ser 1. SB_ACTIVE fue eliminado o 2. mapping_shrinkable() devolvió falso cuando reproduje el error.

Vulnerabilidad de neutralización incorrecta de elementos especiales utilizados en un comando SQL ('Inyección SQL') en FunnelKit Automation By Autonami permite la inyección SQL. Este problema afecta a Automation By Autonami: desde n/a hasta 3.1.2.