Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: s390: soluciona el problema de intercepción de validez cuando gisa está desactivado Podemos encontrarnos con una validez de SIE si gisa se ha deshabilitado mediante el uso del parámetro del kernel "kvm.use_gisa=0" o configurando el atributo sysfs relacionado en N (echo N >/sys/module/kvm/parameters/use_gisa). La validez es causada por un valor no válido en la designación gisa del bloque de control SIE. Esto sucede porque pasamos el origen gisa no inicializado a virt_to_phys() antes de escribirlo en la designación gisa. Para solucionar esto, devolvemos 0 en kvm_s390_get_gisa_desc() si el origen es 0. kvm_s390_get_gisa_desc() se utiliza para determinar qué designación gisa establecer en el bloque de control SIE. Un valor de 0 en la designación gisa deshabilita el uso de gisa. El problema aparece en el kernel del host con el siguiente mensaje del kernel tan pronto como se intenta iniciar un nuevo invitado kvm. kvm: interceptación de validez no controlada 0x1011 WARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101 kvm_handle_sie_intercept+0x42e/0x4d0 [kvm] Modules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables sunrpc mlx5_ib ib_uverbs ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci] CPU: 0 PID: 781237 Comm: CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6 Hardware name: IBM 3931 A01 701 (LPAR) Krnl PSW : 0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 000003d900000027 000003d900000023 0000000000000028 000002cd00000000 000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff 000002cfd82e9000 000002cfd80bc000 0000000000001011 000003d93deda412 000003ff8962df98 000003d93de77ce0 000003d93deb011e 00000359c6daf960 Krnl Code: 000003d93deb0112: c020fffe7259 larl %r2,000003d93de7e5c4 000003d93deb0118: c0e53fa8beac brasl %r14,000003d9bd3c7e70 #000003d93deb011e: af000000 mc 0,0 >000003d93deb0122: a728ffea lhi %r2,-22 000003d93deb0126: a7f4fe24 brc 15,000003d93deafd6e 000003d93deb012a: 9101f0b0 tm 176(%r15),1 000003d93deb012e: a774fe48 brc 7,000003d93deafdbe 000003d93deb0132: 40a0f0ae sth %r10,174(%r15) Call Trace: [<000003d93deb0122>] kvm_handle_sie_intercept+0x432/0x4d0 [kvm] ([<000003d93deb011e>] kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]) [<000003d93deacc10>] vcpu_post_run+0x1d0/0x3b0 [kvm] [<000003d93deaceda>] __vcpu_run+0xea/0x2d0 [kvm] [<000003d93dead9da>] kvm_arch_vcpu_ioctl_run+0x16a/0x430 [kvm] [<000003d93de93ee0>] kvm_vcpu_ioctl+0x190/0x7c0 [kvm] [<000003d9bd728b4e>] vfs_ioctl+0x2e/0x70 [<000003d9bd72a092>] __s390x_sys_ioctl+0xc2/0xd0 [<000003d9be0e9222>] __do_syscall+0x1f2/0x2e0 [<000003d9be0f9a90>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003d9bd3c7f58>] __warn_printk+0xe8/0xf0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mana: Fix RX buf alloc_size adjustment and atomic op panic El búfer RX alloc_size del controlador MANA se pasa a napi_build_skb() para crear SKB. skb_shinfo(skb) se encuentra al final de skb, y su alineación se ve afectada por el alloc_size pasado a napi_build_skb(). El tamaño debe estar alineado correctamente para un mejor rendimiento y operaciones atómicas. De lo contrario, en la CPU ARM64, para ciertas configuraciones de MTU como 4000, las operaciones atómicas pueden entrar en pánico en skb_shinfo(skb)->dataref debido a un error de alineación. Para corregir este error, agregue la alineación adecuada al cálculo alloc_size. Información de pánico de muestra: [253.298819] No se puede manejar la solicitud de paginación del núcleo en la dirección virtual ffff000129ba5cce [253.300900] Información de aborto de memoria: [253.301760] ESR = 0x0000000096000021 [253.302825] EC = 0x25: DABT (EL actual), IL = 32 bits [253.304268] SET = 0, FnV = 0 [253.305172] EA = 0, S1PTW = 0 [253.306103] FSC = 0x21: error de alineación Rastreo de llamada: __skb_clone+0xfc/0x198 skb_clone+0x78/0xe0 raw6_local_deliver+0xfc/0x228 ip6_protocol_deliver_rcu+0x80/0x500 ip6_input_finish+0x48/0x80 ip6_input+0x48/0xc0 ip6_sublist_rcv_finish+0x50/0x78 ip6_sublist_rcv+0x1cc/0x2b8 ipv6_list_rcv+0x100/0x150 __netif_receive_skb_list_core+0x180/0x220 netif_receive_skb_list_internal+0x198/0x2a8 __napi_poll+0x138/0x250 net_rx_action+0x148/0x330 manejar_softirqs+0x12c/0x3a0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: fix xfrm real_dev null pointer dereference No deberíamos establecer real_dev en NULL porque los paquetes pueden estar en tránsito y xfrm podría llamar a xdo_dev_offload_ok() en paralelo. Todas las devoluciones de llamadas suponen que real_dev está establecido. Ejemplo de seguimiento: kernel: BUG: no se puede manejar el error de página para la dirección: 0000000000001030 kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: #PF: acceso de escritura del supervisor en modo kernel kernel: #PF: error_code(0x0002) - página no presente kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping No contaminado 6.7.7+ #12 kernel: Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar el kernel SA: Código: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 000000000000010 R09: 0000000000000014 kernel: R10: 797420303030303030 R11: 3030303030303030 R12: 0000000000000000 núcleo: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 núcleo: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 núcleo: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 núcleo: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: Seguimiento de llamadas: kernel: kernel: ? __die+0x1f/0x60 kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: error al agregar SA kernel: ? page_fault_oops+0x142/0x4c0 kernel: ? do_user_addr_fault+0x65/0x670 kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50 kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: ? exc_page_fault+0x7b/0x180 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim] kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar SA kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (esclavo eni0np1): haciendo que la interfaz sea la nueva activa kernel: bond_ipsec_offload_ok+0x7b/0x90 [vinculación] kernel: xfrm_output+0x61/0x3b0 kernel: bond0: (esclavo eni0np1): bond_ipsec_add_sa_all: no se pudo agregar SA kernel: ip_push_pending_frames+0x56/0x80

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: corregir desreferenciación de puntero nulo en bond_ipsec_offload_ok Debemos comprobar si hay un esclavo activo antes de desreferenciar el puntero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: evitar la ejecución concurrente de tcp_sk_exit_batch Es posible que dos subprocesos llamen a tcp_sk_exit_batch() simultáneamente, una vez desde la cola de trabajo cleanup_net, otra desde una tarea que no pudo clonar una nueva netns. En el último caso, el desenrollado de errores llama a los controladores de salida en orden inverso para las netns "fallidas". tcp_sk_exit_batch() llama a tcp_twsk_purge(). El problema es que desde el commit b099ce2602d8 ("net: Batch inet_twsk_purge"), esta función recoge twsk en cualquier netn moribundo, no solo en el que se pasa a través de la lista exit_batch. Esto significa que el desenrollado de errores de setup_net() puede "robar" y destruir los sockets timewait que pertenecen a las netns que salen. Esto permite que el trabajador de salida netns proceda a llamar a WARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount)); sin la transición esperada de 1 -> 0, que luego falla. Al mismo tiempo, la ruta de desenrollado de error que también está ejecutando inet_twsk_purge() también se mostrará: ADVERTENCIA: .. en lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 ... refcount_dec include/linux/refcount.h:351 [en línea] inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70 inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221 inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304 tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 setup_net+0x714/0xb40 net/core/net_namespace.c:375 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 ... porque refcount_dec() de tw_refcount cayó inesperadamente a 0. Esto no parece un error real (no se perdieron sockets tw y no veo un use-after-free) sino un disparador erróneo de la comprobación de depuración. Agregue un mutex para forzar un orden estricto: la tarea que llama a tcp_twsk_purge() impide que otra tarea realice _dec_and_test final antes de que el propietario del mutex haya eliminado todos los sockets tw de los netn moribundos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net:hns3: se corrige un problema de bloqueo cuando se configura TC durante el reinicio Cuando se configura TC durante el proceso de reinicio, puede causar un bloqueo, el flujo es el siguiente: pf reset start ? ? ...... setup tc ? ? ? ? DOWN: napi_disable() napi_disable()(skip) ? ? ? ? ? ...... ...... ? ? ? ? napi_enable() ? ? UINIT: netif_napi_del() ? ? ...... ? ? INIT: netif_napi_add() ? ? ...... global reset start ? ? ? ? UP: napi_enable()(skip) ...... ? ? ? ? ...... napi_disable() En el proceso de reinicio, el controlador DESACTIVARÁ el puerto y luego UINIT; en este caso, el proceso de configuración tc DESACTIVARÁ el puerto antes de UINIT, lo que provocará el problema. Agrega un proceso DESACTIVADO en UINIT para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atm: idt77252: evitar use after free en dequeue_rx() No podemos desreferenciar "skb" después de llamar a vcc->push() porque skb está liberado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gtp: extraer encabezados de red en gtp_dev_xmit() syzbot/KMSAN informó del uso de uninit-value en get_dev_xmit() [1] Debemos asegurarnos de que el encabezado IPv4 o Ipv6 se extraiga en skb->head antes de acceder a los campos que contienen. Utilice pskb_inet_may_pull() para solucionar este problema. [1] ERROR: KMSAN: valor no inicializado en ipv6_pdp_find drivers/net/gtp.c:220 [en línea] ERROR: KMSAN: valor no inicializado en gtp_build_skb_ip6 drivers/net/gtp.c:1229 [en línea] ERROR: KMSAN: valor no inicializado en gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [en línea] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [en línea] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit incluir/linux/netdevice.h:4913 [en línea] netdev_start_xmit incluir/linux/netdevice.h:4922 [en línea] xmit_one net/core/dev.c:3580 [en línea] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit incluir/linux/netdevice.h:3105 [en línea] paquete_xmit+0x9c/0x6c0 net/paquete/af_packet.c:276 paquete_snd net/paquete/af_packet.c:3145 [en línea] paquete_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [en línea] __se_sys_sendto net/socket.c:2212 [en línea] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 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 creó en: slab_post_alloc_hook mm/slub.c:3994 [en línea] slab_alloc_node mm/slub.c:4037 [en línea] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [en línea] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [en línea] packet_snd net/packet/af_packet.c:3088 [en línea] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 red/socket.c:2204 __do_sys_sendto red/socket.c:2216 [en línea] __se_sys_sendto red/socket.c:2212 [en línea] __x64_sys_sendto+0x125/0x1d0 red/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 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 CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 No contaminado 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/06/2024

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/netfs/fscache_cookie: agregar comprobación "n_accesses" faltante Esto corrige un error de desreferencia de puntero NULL debido a una ejecución de datos que se ve así: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000008 #PF: acceso de lectura de supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 33 PID: 16573 Comm: kworker/u97:799 No contaminado 6.8.7-cm4all1-hp+ #43 Nombre del hardware: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 17/10/2018 Cola de trabajo: events_unbound netfs_rreq_write_to_cache_work RIP: 0010:cachefiles_prepare_write+0x30/0xa0 Código: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10 RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286 RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000 RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438 RBP: 000000000000000 R08: 0000000000278333 R09: 0000000000000001 R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68 R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00 FS: 000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0 Seguimiento de llamadas: ? __die+0x1f/0x70 ? page_fault_oops+0x15d/0x440 ? search_module_extables+0xe/0x40 ? fixup_exception+0x22/0x2f0 ? exc_page_fault+0x5f/0x100 ? asm_exc_page_fault+0x22/0x30 ? cachefiles_prepare_write+0x30/0xa0 netfs_rreq_write_to_cache_work+0x135/0x2e0 process_one_work+0x137/0x2c0 subproceso_trabajador+0x2e9/0x400 ? __pfx_worker_thread+0x10/0x10 kthread+0xcc/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Módulos vinculados en: CR2: 000000000000008 ---[ fin del seguimiento 000000000000000 ]--- Esto sucedió porque fscache_cookie_state_machine() era lento y todavía se estaba ejecutando mientras otro proceso invocaba fscache_unuse_cookie(); Esto llevó a una llamada a fscache_cookie_lru_do_one(), que estableció el indicador FSCACHE_COOKIE_DO_LRU_DISCARD, que fue detectado por fscache_cookie_state_machine(), retirando la cookie a través de cachefiles_withdraw_cookie(), borrando cookie->cache_priv. Al mismo tiempo, otro proceso invocó cachefiles_prepare_write(), que encontró un puntero NULL en esta línea de código: struct cachefiles_object *object = cachefiles_cres_object(cres); La siguiente línea falla, obviamente: struct cachefiles_cache *cache = object->volume->cache; Durante cachefiles_prepare_write(), el contador "n_accesses" no es cero (a través de fscache_begin_operation()). La cookie no debe retirarse hasta que baje a cero. El contador se comprueba mediante fscache_cookie_state_machine() antes de cambiar a FSCACHE_COOKIE_STATE_RELINQUISHING y FSCACHE_COOKIE_STATE_WITHDRAWING (en el "caso FSCACHE_COOKIE_STATE_FAILED"), pero no para FSCACHE_COOKIE_STATE_LRU_DISCARDING ("caso FSCACHE_COOKIE_STATE_ACTIVE"). Este parche agrega la comprobación faltante. Con un contador de acceso distinto de cero, la función retorna y la siguiente llamada fscache_end_cookie_access() pondrá en cola otra llamada fscache_cookie_state_machine() para manejar la FSCACHE_COOKIE_DO_LRU_DISCARD aún pendiente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtla/osnoise: Evitar la desreferenciación NULL en el manejo de errores. Si la asignación "tool->data" falla, entonces no es necesario llamar a osnoise_free_top() y, de hecho, hacerlo provocará una desreferenciación NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfs: No desalojar inodo bajo el contexto de recorrido lru de inodo El proceso de recuperación de inodo (ver función prune_icache_sb) recopila todos los inodos recuperables y los marca con el indicador I_FREEING al principio, en ese momento, otros procesos se atascarán si intentan obtener estos inodos (ver función find_inode_fast), luego el proceso de recuperación destruye los inodos mediante la función dispose_list(). Algunos sistemas de archivos (por ejemplo, ext4 con la función ea_inode, ubifs con xattr) pueden realizar una búsqueda de inodo en la función de devolución de llamada de expulsión de inodo, si la búsqueda de inodo se opera bajo el contexto de recorrido lru de inodo, pueden ocurrir problemas de interbloqueo. Caso 1: En la función ext4_evict_inode(), la búsqueda de inodo ea podría ocurrir si la característica ea_inode está habilitada, el proceso de búsqueda se quedará atascado bajo el contexto de desalojo de esta manera: 1. El archivo A tiene un inodo i_reg y un inodo ea i_ea 2. getfattr(A, xattr_buf) // i_ea se agrega a lru // lru->i_ea 3. Luego, los siguientes tres procesos se ejecutan de esta manera: PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg se agrega a lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // establece el estado del inodo inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm archivo A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink es 0, desalojar ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(i_ea) ----? Bloqueo AA dispose_list // no puede ser ejecutado por prune_icache_sb wake_up_bit(&i_ea->i_state) Caso 2: En la función de escritura de inodo eliminado ubifs_jnl_write_inode(), el proceso de eliminación de archivo retiene BASEHD wbuf->io_mutex mientras obtiene el inodo xattr, que podría competir con el proceso de recuperación de inodo (el proceso de recuperación podría intentar bloquear wbuf->io_mutex de BASEHD en la función de desalojo de inodo), entonces ocurriría un problema de bloqueo ABBA de la siguiente manera: 1. El archivo A tiene un inodo ia y un xattr (con un inodo ixa), el archivo B normal tiene un inodo ib y un xattr. 2. getfattr(A, xattr_buf) // ixa se agrega a lru // lru->ixa 3. Luego, los siguientes tres procesos se ejecutan de esta manera: PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib e ia se agregan a lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // establece el estado del inodo inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm archivo B ib->nlink = 0 rm archivo A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Bloquear wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink es 0, desalojar | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ? ubifs_jnl_write_inode Bloqueo ABBA ?-----make_reservation(BASEHD) dispose_list // no puede ser ejecutado por prune_icache_sb wake_up_bit(&ixa->i_state) Corrija el posible bloqueo utilizando el nuevo indicador de estado de inodo I_LRU_ISOLATING para fijar el inodo en la memoria mientras inode_lru_isolate( ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xhci: Fix Panther point NULL point deref at full-speed re-enumeration reenumerar dispositivos de velocidad completa después de un comando de dispositivo de dirección fallido puede desencadenar una desreferencia de puntero NULL. Los dispositivos de velocidad completa pueden necesitar reconfigurar el valor 0 Max Packet Size del endpoint durante la enumeración. Usb core llama a usb_ep0_reinit() en este caso, que termina llamando a xhci_configure_endpoint(). En Panther point xHC, la función xhci_configure_endpoint() verificará y reservará adicionalmente el ancho de banda en el software. Otros hosts hacen esto en el hardware Si el comando de dispositivo de dirección xHC falla, se asigna una nueva estructura xhci_virt_device como parte de la rehabilitación de la ranura, pero los punteros de la tabla de ancho de banda no se configuran correctamente aquí. Esto activa la desreferencia del puntero NULL la próxima vez que se llama a usb_ep0_reinit() y xhci_configure_endpoint() intenta verificar y reservar el ancho de banda [46710.713538] usb 3-1: nuevo dispositivo USB de velocidad completa número 5 que usa xhci_hcd [46710.713699] usb 3-1: el dispositivo no responde a la dirección de configuración. [46710.917684] usb 3-1: el dispositivo no responde a la dirección de configuración. [46711.125536] usb 3-1: el dispositivo no acepta la dirección 5, error -71 [46711.125594] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000008 [46711.125600] #PF: acceso de lectura del supervisor en modo kernel [46711.125603] #PF: error_code(0x0000) - página no presente [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 No contaminado 6.10.3_2 #1 [46711.125620] Nombre del hardware: Gigabyte Technology Co., Ltd. [46711.125623] Cola de trabajo: usb_hub_wq hub_event [usbcore] [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c Solucione esto asegurándose de que los punteros de la tabla de ancho de banda estén configurados correctamente después de un comando de dispositivo de dirección fallido y, además, evitando verificar el ancho de banda en casos como este donde no se agregan ni eliminan endpoints reales, es decir, solo se evalúa el contexto para el endpoint de control predeterminado 0.