Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/mlx5: Arreglar el uso implícito de ODP después de la liberación Evitar la puesta en cola doble del trabajo de destrucción de mr de ODP implícito mediante __xa_cmpxchg() para asegurarse de que esta sea la única vez que destruyamos este mr específico. Sin este cambio, podríamos intentar invalidar este mr dos veces, lo que a su vez podría resultar en poner en cola una destrucción de trabajo de MR dos veces, y eventualmente el segundo trabajo podría ejecutarse después de que el MR se liberara debido al primer trabajo, causando un user after free y un seguimiento a continuación. refcount_t: desbordamiento insuficiente; use after free. ADVERTENCIA: CPU: 2 PID: 12178 at lib/refcount.c:28 refcount_warn_saturate+0x12b/0x130 Modules linked in: bonding ib_ipoib vfio_pci ip_gre geneve nf_tables ip6_gre gre ip6_tunnel tunnel6 ipip tunnel4 ib_umad rdma_ucm mlx5_vfio_pci vfio_pci_core vfio_iommu_type1 mlx5_ib vfio ib_uverbs mlx5_core iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs] CPU: 2 PID: 12178 Comm: kworker/u20:5 Not tainted 6.5.0-rc1_net_next_mlx5_58c644e #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: events_unbound free_implicit_child_mr_work [mlx5_ib] RIP: 0010:refcount_warn_saturate+0x12b/0x130 Code: 48 c7 c7 38 95 2a 82 c6 05 bc c6 fe 00 01 e8 0c 66 aa ff 0f 0b 5b c3 48 c7 c7 e0 94 2a 82 c6 05 a7 c6 fe 00 01 e8 f5 65 aa ff <0f> 0b 5b c3 90 8b 07 3d 00 00 00 c0 74 12 83 f8 01 74 13 8d 50 ff RSP: 0018:ffff8881008e3e40 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027 RDX: ffff88852c91b5c8 RSI: 0000000000000001 RDI: ffff88852c91b5c0 RBP: ffff8881dacd4e00 R08: 00000000ffffffff R09: 0000000000000019 R10: 000000000000072e R11: 0000000063666572 R12: ffff88812bfd9e00 R13: ffff8881c792d200 R14: ffff88810011c005 R15: ffff8881002099c0 FS: 0000000000000000(0000) GS:ffff88852c900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5694b5e000 CR3: 00000001153f6003 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? refcount_warn_saturate+0x12b/0x130 free_implicit_child_mr_work+0x180/0x1b0 [mlx5_ib] process_one_work+0x1cc/0x3c0 worker_thread+0x218/0x3c0 kthread+0xc6/0xf0 ret_from_fork+0x1f/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: agregar cpu_to_node faltante a kvzalloc_node en mlx5e_open_xdpredirect_sq kvzalloc_node no está realizando una verificación en tiempo de ejecución en el argumento del nodo (__alloc_pages_node_noprof tiene un VM_BUG_ON, pero se expande a nada en las compilaciones !CONFIG_DEBUG_VM), por lo que realizar cualquier operación ethtool/netlink que llame a mlx5e_open en una CPU que sea más grande que MAX_NUMNODES desencadena el acceso OOB y el pánico (vea el seguimiento a continuación). Agregue la llamada cpu_to_node faltante para convertir la identificación de la CPU en identificación del nodo. [ 165.427394] mlx5_core 0000:5c:00.0 beth1: Enlace activo [ 166.479327] ERROR: no se puede manejar el error de página para la dirección: 0000000800000010 [ 166.494592] #PF: acceso de lectura del supervisor en modo kernel [ 166.505995] #PF: error_code(0x0000) - página no presente ... [ 166.816958] Seguimiento de llamadas: [ 166.822380] [ 166.827034] ? __die_body+0x64/0xb0 [ 166.834774] ? page_fault_oops+0x2cd/0x3f0 [ 166.843862] ? exc_page_fault+0x63/0x130 [ 166.852564] ? asm_exc_page_fault+0x22/0x30 [ 166.861843] ? __kvmalloc_node_noprof+0x43/0xd0 [ 166.871897] ? get_partial_node+0x1c/0x320 [ 166.880983] ? deactivate_slab+0x269/0x2b0 [ 166.890069] ___slab_alloc+0x521/0xa90 [ 166.898389] ? __kvmalloc_node_noprof+0x43/0xd0 [ 166.908442] __kmalloc_node_noprof+0x216/0x3f0 [ 166.918302] ? __kvmalloc_node_noprof+0x43/0xd0 [ 166.928354] __kvmalloc_node_noprof+0x43/0xd0 [ 166.938021] mlx5e_open_channels+0x5e2/0xc00 [ 166.947496] mlx5e_open_locked+0x3e/0xf0 [ 166.956201] mlx5e_open+0x23/0x50 [ 166.963551] __dev_open+0x114/0x1c0 [ 166.971292] __dev_change_flags+0xa2/0x1b0 [ 166.980378] dev_change_flags+0x21/0x60 [ 166.988887] do_setlink+0x38d/0xf20 [ 166.996628] ? ep_poll_callback+0x1b9/0x240 [ 167.005910] ? __nla_validate_parse.llvm.10713395753544950386+0x80/0xd70 [ 167.020782] ? __wake_up_sync_key+0x52/0x80 [ 167.030066] ? __mutex_lock+0xff/0x550 [ 167.038382] ? security_capable+0x50/0x90 [ 167.047279] rtnl_setlink+0x1c9/0x210 [ 167.055403] ? ep_poll_callback+0x1b9/0x240 [ 167.064684] ? security_capable+0x50/0x90 [ 167.073579] rtnetlink_rcv_msg+0x2f9/0x310 [ 167.082667] ? rtnetlink_bind+0x30/0x30 [ 167.091173] netlink_rcv_skb+0xb1/0xe0 [ 167.099492] netlink_unicast+0x20f/0x2e0 [ 167.108191] netlink_sendmsg+0x389/0x420 [ 167.116896] __sys_sendto+0x158/0x1c0 [ 167.125024] __x64_sys_sendto+0x22/0x30 [ 167.133534] do_syscall_64+0x63/0x130 [ 167.141657] ? __irq_exit_rcu.llvm.17843942359718260576+0x52/0xd0 [ 167.155181] entry_SYSCALL_64_after_hwframe+0x4b/0x53

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: eliminar entrada secpath intermedia en modo de descarga de paquetes Los paquetes manejados por hardware han agregado secpath como una forma de informar al código central de XFRM que esta ruta ya fue manejada. Ese secpath no es necesario en absoluto después de que se verifica la política y se elimina más adelante en la pila. Sin embargo, en el caso de que el reenvío de IP esté habilitado (/proc/sys/net/ipv4/ip_forward), ese secpath no se elimina y los paquetes que ya fueron manejados se reingresan a la ruta TX del controlador con xfrm_offload establecido. En este caso, se observa el siguiente pánico del kernel en mlx5: mlx5_core 0000:04:00.0 enp4s0f0np0: Enlace activo mlx5_core 0000:04:00.1 enp4s0f1np1: Enlace activo Inicializando socket de enlace de red XFRM Controlador de dispositivo XFRM IPsec ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000000 #PF: obtención de instrucción de supervisor en modo kernel #PF: error_code(0x0010) - página no presente PGD 0 P4D 0 Oops: Oops: 0010 [#1] PREEMPT SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 No contaminado 6.13.0-rc1-alex #3 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 01/04/2014 RIP: 0010:0x0 Código: No se puede acceder a los bytes del código de operación en 0xffffffffffffffd6. RSP: 0018:ffffb87380003800 EFLAGS: 00010206 RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00 RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010 R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00 R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e FS: 000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0 Rastreo de llamadas: ? show_regs+0x63/0x70 ? __die_body+0x20/0x60 ? __die+0x2b/0x40 ? page_fault_oops+0x15c/0x550 ? do_user_addr_fault+0x3ed/0x870 ? exc_page_fault+0x7f/0x190 ? asm_exc_page_fault+0x27/0x30 mlx5e_ipsec_handle_tx_skb+0xe7/0x2f0 [mlx5_core] mlx5e_xmit+0x58e/0x1980 [mlx5_core] ? __fib_lookup+0x6a/0xb0 dev_hard_start_xmit+0x82/0x1d0 sch_direct_xmit+0xfe/0x390 __dev_queue_xmit+0x6d8/0xee0 ? __fib_lookup+0x6a/0xb0 ? temporizador_de_adición_interna+0x48/0x70 ? temporizador_mod+0xe2/0x2b0 salida_de_resolución_vecina+0x115/0x1b0 __neigh_update+0x26a/0xc50 neigh_update+0x14/0x20 proceso_arp+0x2cb/0x8e0 ? __napi_build_skb+0x5e/0x70 arp_rcv+0x11e/0x1c0 ? cadena_de_llamadas_del_notificador_atómico+0x3b/0x50 ? manejador_irq_int+0x15/0x20 [mlx5_core] manejador_softirqs+0xb9/0x2f0 ? asm_common_interrupt+0x27/0x40 RIP: 0010:pv_native_safe_halt+0xb/0x10 Código: 09 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 22 0f 1f 84 00 00 00 00 00 90 eb 07 0f 00 2d 7f e9 36 00 fb 40 00 83 ff 07 77 21 89 ff ff 24 fd 88 3d a1 bd 0f 21 f8 RSP: 0018:ffffffffbe603de8 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 000000000000000 RCX: 0000000f92f46680 RDX: 0000000000000037 RSI: 00000000ffffffff RDI: 00000000000518d4 RBP: ffffffffbe603df0 R08: 000000cd42e4dffb R09: ffffffffbe603d70 R10: 0000004d80d62680 R11: 00000000000000001 R12: ffffffffbe60bf40 R13: 0000000000000000 R14: 00000000000000000 R15: ffffffffbe60aff8 ? setup_ghcb+0xe/0x130 common_startup_64+0x13e/0x141 Módulos vinculados en: esp4_offload esp4 xfrm_interface xfrm6_tunnel tunnel4 tunnel6 xfrm_user xfrm_algo binf ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: Se corrige un posible bloqueo cuando falla la configuración de bsg Si bsg_setup_queue() falla, a bsg_queue se le asigna un valor distinto de NULL. En consecuencia, en mpi3mr_bsg_exit(), la condición "if(!mrioc->bsg_queue)" no se cumplirá, lo que evitará que la ejecución ingrese a bsg_remove_queue(), lo que podría provocar el siguiente bloqueo: ERROR: desreferencia de puntero NULL del núcleo, dirección: 000000000000041c Seguimiento de llamadas: mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr] mpi3mr_remove+0x6f/0x340 [mpi3mr] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19d/0x220 unbind_store+0xa4/0xb0 kernfs_fop_write_iter+0x11f/0x200 vfs_write+0x1fc/0x3e0 ksys_write+0x67/0xe0 hacer_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x78/0xe2

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: davicom: fix UAF in dm9000_drv_remove dm son datos privados de netdev y no se pueden usar después de la llamada a free_netdev(). El uso de dm después de free_netdev() puede provocar un error de UAF. Solucione el problema moviendo free_netdev() al final de la función. Esto es similar al problema solucionado en el commit ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove"). Nuestra herramienta de análisis estático detecta este error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vxlan: Corregir valor no inicializado en vxlan_vnifilter_dump() KMSAN informó un acceso a valor no inicializado en vxlan_vnifilter_dump() [1]. Si la longitud del payload del mensaje netlink es menor que sizeof(struct tunnel_msg), vxlan_vnifilter_dump() accede a bytes más allá del mensaje. Esto puede provocar un acceso a valor no inicializado. Corrija esto devolviendo un error en tales situaciones. [1] ERROR: KMSAN: uninit-value in vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422 vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6786 netlink_dump+0x93e/0x15f0 net/netlink/af_netlink.c:2317 __netlink_dump_start+0x716/0xd60 net/netlink/af_netlink.c:2432 netlink_dump_start include/linux/netlink.h:340 [inline] rtnetlink_dump_start net/core/rtnetlink.c:6815 [inline] rtnetlink_rcv_msg+0x1256/0x14a0 net/core/rtnetlink.c:6882 netlink_rcv_skb+0x467/0x660 net/netlink/af_netlink.c:2542 rtnetlink_rcv+0x35/0x40 net/core/rtnetlink.c:6944 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline] netlink_unicast+0xed6/0x1290 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x1092/0x1230 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:726 ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637 __sys_sendmsg net/socket.c:2669 [inline] __do_sys_sendmsg net/socket.c:2674 [inline] __se_sys_sendmsg net/socket.c:2672 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672 x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4110 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x800/0xe80 mm/slub.c:4205 kmalloc_reserve+0x13b/0x4b0 net/core/skbuff.c:587 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] netlink_alloc_large_skb+0xa5/0x280 net/netlink/af_netlink.c:1196 netlink_sendmsg+0xac9/0x1230 net/netlink/af_netlink.c:1866 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:726 ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637 __sys_sendmsg net/socket.c:2669 [inline] __do_sys_sendmsg net/socket.c:2674 [inline] __se_sys_sendmsg net/socket.c:2672 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672 x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 30991 Comm: syz.4.10630 Not tainted 6.12.0-10694-gc44daa7e3c73 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: rose: se corrige la ejecución de temporizadores contra subprocesos de usuario Los temporizadores de Rose solo adquieren el bloqueo de giro del socket, sin verificar si el socket es propiedad de un subproceso de usuario. Agregue una verificación y vuelva a armar los temporizadores si es necesario. ERROR: KASAN: slab-use-after-free en rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Lectura de tamaño 2 en la dirección ffff88802f09b82a por la tarea swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 No contaminado 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Rastreo de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [en línea] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [en línea] __run_timers kernel/time/timer.c:2418 [en línea] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [en línea] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [en línea] invoke_softirq kernel/softirq.c:435 [en línea] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [en línea] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049

En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: ipmr: no llamar a mr_mfc_uses_dev() para entradas no resueltas syzbot descubrió que llamar a mr_mfc_uses_dev() para entradas no resueltas provocaría un bloqueo [1], porque c->mfc_un.res.minvif / c->mfc_un.res.maxvif son alias de "struct sk_buff_head unresolved", que contienen dos punteros. Este código nunca funcionó, eliminémoslo. [1] No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff5fff2d536613 KASAN: tal vez un acceso a memoria salvaje en el rango [0xfffefff96a9b3098-0xfffefff96a9b309f] Módulos vinculados: CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 No contaminado 6.13.0-rc7-syzkaller-g1950a0af2d55 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [en línea] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [en línea] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334 Rastreo de llamadas: mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [en línea] (P) mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P) mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317 netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973 sock_recvmsg_nosec net/socket.c:1033 [en línea] sock_recvmsg net/socket.c:1055 [en línea] sock_read_iter+0x2d8/0x40c net/socket.c:1125 new_sync_read fs/read_write.c:484 [en línea] vfs_read+0x740/0x970 fs/read_write.c:565 ksys_read+0x15c/0x26c fs/read_write.c:708

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: manejar errores que nilfs_prepare_chunk() puede devolver Serie de parches "nilfs2: soluciona problemas con operaciones de cambio de nombre". Esta serie corrige los fallos de comprobación BUG_ON informados por syzbot en torno a las operaciones de cambio de nombre, y un problema de comportamiento menor en el que el mtime de un directorio secundario cambia cuando se le cambia el nombre en lugar de moverlo. Este parche (de 2): Las rutinas de manipulación de directorios nilfs_set_link() y nilfs_delete_entry() reescriben la entrada del directorio en el folio/página leído previamente por nilfs_find_entry(), por lo que se omite el manejo de errores asumiendo que nilfs_prepare_chunk(), que prepara el búfer para la reescritura, siempre tendrá éxito para estos. Y si se devuelve un error, activa las comprobaciones BUG_ON() heredadas en cada rutina. Esta suposición es errónea, como lo demuestra syzbot: la capa de búfer llamada por nilfs_prepare_chunk() puede llamar a nilfs_get_block() si es necesario, lo que puede fallar debido a la corrupción de metadatos u otras razones. Esto ha estado ahí desde siempre, pero las comprobaciones de cordura mejoradas y el manejo de errores pueden haberlo hecho más reproducible en pruebas de fuzzing. Solucione este problema agregando rutas de error faltantes en nilfs_set_link(), nilfs_delete_entry() y su llamador nilfs_rename().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: no fuerza la depuración del folio si se hace referencia al búfer Serie de parches "nilfs2: protege los cabezales de búfer ocupados de ser borrados a la fuerza". Esta serie corrige los problemas de inconsistencia del estado del cabezal de búfer informados por syzbot que ocurren cuando el sistema de archivos está dañado y vuelve a solo lectura, y el problema asociado de uso del cabezal de búfer después de la liberación. Este parche (de 2): Syzbot ha informado que después de que nilfs2 detecta la corrupción del sistema de archivos y vuelve a solo lectura, pueden ocurrir inconsistencias en el estado del búfer. Una de las inconsistencias es que cuando nilfs2 llama a mark_buffer_dirty() para establecer un búfer de datos o metadatos como sucio, pero detecta que el búfer no está en el estado actualizado: ADVERTENCIA: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The other is when nilfs_btree_propagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be: WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Ambos problemas son causados por las devoluciones de llamadas que manejan las solicitudes de escritura de página/folio, borran a la fuerza varios estados, incluido el estado de trabajo de los búferes que contienen, en momentos inesperados cuando detectan una reserva de solo lectura. Solucione estos problemas verificando si se hace referencia al búfer antes de borrar el estado de la página/folio y omitiendo la limpieza si es así.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: evitar especulaciones de reg-wait Con *ENTER_EXT_ARG_REG en lugar de pasar un puntero de usuario con argumentos para el bucle de espera, el usuario puede especificar un desplazamiento en una región de memoria preasignada, en cuyo caso [offset, offset + sizeof(io_uring_reg_wait)) se interpretará como el argumento. Como direccionamos una matriz del kernel usando un índice dado por el usuario, sería un tema de tipo especulativo de exploits. Use array_index_nospec() para evitar eso. Asegúrese de no pasar el tamaño completo de la región, sino truncarlo por el desplazamiento máximo permitido considerando el tamaño de la estructura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries/iommu: No anule la configuración de la ventana si nunca se configuró En pSeries, cuando el usuario intenta utilizar el mismo contenedor vfio utilizado por un grupo iommu diferente, spapr_tce_set_window() devuelve -EPERM y la limpieza posterior conduce al siguiente bloqueo. El kernel intentó leer la página del usuario (308) - exploit attempt? BUG: Kernel NULL pointer dereference on read at 0x00000308 Faulting instruction address: 0xc0000000001ce358 Oops: Kernel access of bad area, sig: 11 [#1] NIP: c0000000001ce358 LR: c0000000001ce05c CTR: c00000000005add0 NIP [c0000000001ce358] spapr_tce_unset_window+0x3b8/0x510 LR [c0000000001ce05c] spapr_tce_unset_window+0xbc/0x510 Call Trace: spapr_tce_unset_window+0xbc/0x510 (unreliable) tce_iommu_attach_group+0x24c/0x340 [vfio_iommu_spapr_tce] vfio_container_attach_group+0xec/0x240 [vfio] vfio_group_fops_unl_ioctl+0x548/0xb00 [vfio] sys_ioctl+0x754/0x1580 system_call_exception+0x13c/0x330 system_call_vectored_common+0x15c/0x2ec --- interrupt: 3000 Solucione esto haciendo que la verificación de valores nulos sea para la tabla pasada a spapr_tce_unset_window().