Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: padata: corrección de UAF en padata_reorder Se encontró un error al ejecutar la prueba ltp: ERROR: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01). This can be explained as bellow: pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF } En la función padata_reorder, cuando se repite en 'while', si se elimina el alg, el refcnt puede disminuirse a 0 antes de ingresar a 'padata_find_next', lo que lleva a UAF. Como se mencionó en [1], se supone que do_serial se debe llamar con los BH deshabilitados y siempre ocurre bajo la protección de RCU, para abordar este problema, agreguesynchronous_rcu() en 'padata_free_shell' y espere a que finalicen todas las llamadas a _do_serial. [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Envía señales de forma asincrónica si los programas BPF !preemptible pueden ejecutarse en todo tipo de contextos y cuando un programa que se ejecuta en un contexto no preemptible utiliza la función kfunc bpf_send_signal(), causará problemas porque esta función kfunc puede suspenderse. Cambie `irqs_disabled()` a `!preemptible()`.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nbd: no permitir la reconexión después de la desconexión El siguiente proceso puede causar el nbd_config UAF: 1) grab nbd_config temporarily; 2) nbd_genl_disconnect() flush all recv_work() and release the initial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero 3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work) 4) step 1) release the reference; 5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAF Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so that nbd_genl_reconfigure() will fail.

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().