Vulnerabilidades

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: 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: 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: 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: mptcp: gestionar la desconexión de fastopen correctamente Syzbot pudo desencadenar una corrupción del flujo de datos: ADVERTENCIA: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024 Modules linked in: CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024 Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 <0f> 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07 RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293 RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928 R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000 R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000 FS: 00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074 mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493 release_sock+0x1aa/0x1f0 net/core/sock.c:3640 inet_wait_for_connect net/ipv4/af_inet.c:609 [inline] __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703 mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755 mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:726 ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583 ___sys_sendmsg net/socket.c:2637 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2669 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 RIP: 0033:0x7f6e86ebfe69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69 RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003 RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508 La causa raíz es la mala gestión de la función de desconexión () generada internamente por el protocolo MPTCP en caso de errores de conexión FASTOPEN. Resuelva el problema aumentando el contador de desconexiones de socket incluso en un caso como ese, para permitir que otros subprocesos que esperan en el mismo bloqueo de socket generen errores correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: pm: solo se establece fullmesh para el extremo final del subflujo Con el administrador de rutas en el kernel, es posible cambiar el indicador 'fullmesh'. El código en mptcp_pm_nl_fullmesh() espera cambiarlo solo en los puntos finales 'subflow', para recrear más o menos subflujos usando la dirección vinculada. Desafortunadamente, el gancho set_flags() era un poco más permisivo y permitía que los puntos finales 'implícitos' obtuvieran el indicador 'fullmesh' mientras que antes no estaba permitido. Eso es lo que syzbot encontró, lo que activó la siguiente advertencia: ADVERTENCIA: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 __mark_subflow_endp_available net/mptcp/pm_netlink.c:1496 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_pm_nl_fullmesh net/mptcp/pm_netlink.c:1980 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_nl_set_flags net/mptcp/pm_netlink.c:2003 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_pm_nl_set_flags+0x974/0xdc0 net/mptcp/pm_netlink.c:2064 Modules linked in: CPU: 0 UID: 0 PID: 6499 Comm: syz.1.413 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_netlink.c:1496 [inline] RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_netlink.c:1980 [inline] RIP: 0010:mptcp_nl_set_flags net/mptcp/pm_netlink.c:2003 [inline] RIP: 0010:mptcp_pm_nl_set_flags+0x974/0xdc0 net/mptcp/pm_netlink.c:2064 Code: 01 00 00 49 89 c5 e8 fb 45 e8 f5 e9 b8 fc ff ff e8 f1 45 e8 f5 4c 89 f7 be 03 00 00 00 e8 44 1d 0b f9 eb a0 e8 dd 45 e8 f5 90 <0f> 0b 90 e9 17 ff ff ff 89 d9 80 e1 07 38 c1 0f 8c c9 fc ff ff 48 RSP: 0018:ffffc9000d307240 EFLAGS: 00010293 RAX: ffffffff8bb72e03 RBX: 0000000000000000 RCX: ffff88807da88000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000d307430 R08: ffffffff8bb72cf0 R09: 1ffff1100b842a5e R10: dffffc0000000000 R11: ffffed100b842a5f R12: ffff88801e2e5ac0 R13: ffff88805c214800 R14: ffff88805c2152e8 R15: 1ffff1100b842a5d FS: 00005555619f6500(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002840 CR3: 00000000247e6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb14/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2542 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:726 ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583 ___sys_sendmsg net/socket.c:2637 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2669 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 RIP: 0033:0x7f5fe8785d29 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff571f5558 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f5fe8975fa0 RCX: 00007f5fe8785d29 RDX: 0000000000000000 RSI: 0000000020000480 RDI: 0000000000000007 RBP: 00007f5fe8801b08 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f5fe8975fa0 R14: 00007f5fe8975fa0 R15: 000000 ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: consolidar el estado de las subopciones MPTCP mantiene el estado de las subopciones recibidas en la máscara de bits que contiene las subopciones recibidas y en varios campos de bits que contienen información adicional por subopción. Poner a cero la máscara de bits antes del análisis no es suficiente para garantizar un estado consistente, y el código MPTCP tiene que borrar adicionalmente algunos campos de bits según la subopción analizada en realidad. El esquema anterior es frágil y syzbot logró activar una ruta donde un campo de bits relevante no se borra/inicializa: ERROR: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: usb: rtl8150: habilitar la comprobación básica de endpoints Syzkaller informa [1] que ha encontrado un problema común de uso de un tipo de endpoint USB incorrecto durante la etapa de envío de URB. Esto, a su vez, activa una advertencia que se muestra a continuación. Por ahora, habilite la comprobación simple de endpoints (específicamente, los eps masivos y de interrupción, el control de prueba uno no es esencial) para mitigar el problema con vistas a realizar otros cambios cosméticos relacionados más adelante, si son necesarios. [1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ... Este cambio no se ha probado en hardware real.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kernel: tenga más cuidado con los fallos de dup_mmap() y el registro de uprobe Si una asignación de memoria falla durante dup_mmap(), el árbol de maple puede quedar en un estado inseguro para otros iteradores además de la ruta de salida. Todos los bloqueos se eliminan antes de la llamada a exit_mmap() (en mm/mmap.c), pero se puede llegar al mm_struct incompleto a través de (al menos) el rmap que encuentra los vmas que tienen un puntero de vuelta al mm_struct. Hasta este punto, no ha habido problemas para poder encontrar un mm_struct que solo se haya inicializado parcialmente. Syzbot pudo hacer que el mm_struct incompleto fallara con los cambios de bifurcación recientes, por lo que se ha demostrado que no es seguro usar el mm_struct que no se ha inicializado, como se hace referencia en el enlace a continuación. Aunque 8ac662f5da19f ("fork: avoid inappropriate uprobe access to invalid mm") solucionó el acceso a uprobe, no elimina por completo la carrera. Este parche establece MMF_OOM_SKIP para evitar la iteración de las vmas en el lado oom (aunque es extremadamente improbable que se seleccione como víctima de oom en la ventana de carrera), y establece MMF_UNSTABLE para evitar que otros usuarios potenciales utilicen una mm_struct parcialmente inicializada. Al registrar vmas para uprobe, omite las vmas en un mm que esté marcado como inestable. Modificar una vma en un mm inestable puede causar problemas si el mm no está completamente inicializado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: gestión correcta de la compresión extrema de memoria Las pruebas con iperf3 utilizando el empalmador de protocolo "pasta" han revelado un problema en la forma en que tcp gestiona la publicidad de ventanas en situaciones de compresión extrema de memoria. Bajo presión de memoria, un endpoint de socket puede anunciar temporalmente una ventana de tamaño cero, pero esto no se almacena como parte de los datos del socket. El razonamiento detrás de esto es que se considera una configuración temporal que no debería influir en ningún cálculo posterior. Sin embargo, si nos quedamos en un valor desafortunado del tamaño de ventana actual, el algoritmo que selecciona un nuevo valor fallará constantemente en anunciar una ventana distinta de cero una vez que hayamos liberado suficiente memoria. Esto significa que la noción de este lado del tamaño de ventana actual es diferente de la última anunciada al par, lo que hace que este último no envíe ningún dato para resolver la situación. El problema ocurre en el lado del servidor iperf3, y el socket en cuestión es un socket completamente normal con la configuración predeterminada para el kernel fedora40. No utilizamos SO_PEEK o SO_RCVBUF en el socket. El siguiente extracto de una sesión de registro, con comentarios propios agregados, muestra con más detalle lo que está sucediendo: // tcp_v4_rcv(->) // tcp_rcv_established(->) [5201<->39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ==== [5201<->39222]: tcp_data_queue(->) [5201<->39222]: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0] [5201<->39222]: tcp_data_queue(<-) [5201<->39222]: __tcp_transmit_skb(->) [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] [5201<->39222]: tcp_select_window(->) [5201<->39222]: (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] returning 0 [5201<->39222]: tcp_select_window(<-) [5201<->39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160 [5201<->39222]: [__tcp_transmit_skb(<-) [5201<->39222]: tcp_rcv_established(<-) [5201<->39222]: tcp_v4_rcv(<-) // La cola de recepción está en 85 búferes y nos hemos quedado sin memoria. // Descartamos el búfer entrante, aunque esté en secuencia, y decidimos // enviar un anuncio con una ventana de cero. // No actualizamos tp->rcv_wnd y tp->rcv_wup en consecuencia, lo que significa // que reducimos incondicionalmente la ventana. [5201<->39222]: tcp_recvmsg_locked(->) [5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 [5201<->39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368] [5201<->39222]: [new_win >= (2 * win_now) ? --> time_to_ack = 0] [5201<->39222]: NOT calling tcp_send_ack() [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] [5201<->39222]: __tcp_cleanup_rbuf(<-) [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0] returning 6104 bytes [5201<->39222]: tcp_recvmsg_locked(<-) // Después de cada lectura, el algoritmo para calcular la nueva ventana de recepción // en __tcp_cleanup_rbuf() encuentra que es demasiado pequeña para anunciar // o actualizar tp->rcv_wnd. // Mientras tanto, el par piensa que la ventana es cero y no enviará // más datos para activar una actualización desde el lado del modo de interrupción. [5201<->39222]: tcp_recvmsg_locked(->) [5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 [5201<->39222]: [new_win = 262144, win_now = 131184, 2 * win_n ---truncada---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/rose: evitar desbordamientos de números enteros en rose_setsockopt() En caso de que se pasen argumentos impredeciblemente grandes a rose_setsockopt() y se multipliquen por valores adicionales además de eso, pueden ocurrir desbordamientos de números enteros. Haga lo mínimo más seguro y solucione estos problemas comprobando el contenido de 'opt' y devolviendo -EINVAL si es demasiado grande. Además, cambie a int sin signo y elimine la comprobación inútil para 'opt' negativo en el caso de ROSE_IDLE.