Vulnerabilidades

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: sctp: corrige null-ptr-deref en reuseport_add_sock(). syzbot informó un null-ptr-deref al acceder a sk2->sk_reuseport_cb en reuseport_add_sock(). [0] La reproducción primero crea un oyente con SO_REUSEPORT. Luego, crea otro oyente en el mismo puerto y al mismo tiempo cierra el primer oyente. El segundo listen() llama a reuseport_add_sock() con el primer oyente como sk2, donde no se espera que sk2->sk_reuseport_cb se borre al mismo tiempo, pero close() lo borra mediante reuseport_detach_sock(). El problema es que SCTP no sincroniza correctamente reuseport_alloc(), reuseport_add_sock() y reuseport_detach_sock(). La persona que llama a reuseport_alloc() y reuseport_{add,detach}_sock() debe proporcionar sincronización para los sockets que están clasificados en el mismo grupo de reuseport. De lo contrario, dichos sockets forman múltiples grupos de reutilización idénticos y todos los grupos excepto uno quedarían silenciosamente muertos. 1. Dos sockets llaman a listening() simultáneamente 2. No se encuentra ningún socket en el mismo grupo en sctp_ep_hashtable[] 3. Dos sockets llaman a reuseport_alloc() y forman dos grupos de reuseport 4. Solo un grupo que llega primero en __sctp_rcv_lookup_endpoint() recibe paquetes entrantes también, podría producirse el null-ptr-deref informado. TCP/UDP garantiza que eso no sucederá si se mantiene el bloqueo del depósito hash. Apliquemos la estrategia de bloqueo a __sctp_hash_endpoint() y __sctp_unhash_endpoint(). [0]: Vaya: fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x0000000000000010-0x0000000000000017] CPU: 1 UID: 0 PID: 230 Comm: syz-executor119 No contaminado 6.10.0-syzkaller-12585-g301927d2d2eb #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/06/2024 RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/ sock_reuseport.c:350 Código: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 < 42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14 RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202 RAX: 0000000000000002 X: ffff8880252ddf98 RCX: ffff888079478000 RDX: 0000000000000000 RSI: 00000000000000001 RDI: 0000000000000012 RBP : 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385 R10: dffffc0000000000 R11: ffffbfff1fef386 R12: ffff8880252ddac0 R13: dffffc0000000000 : 0000000000000000 R15: 0000000000000000 FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: __sctp_hash_endpoint net/sctp/input.c:762 [en línea] sctp_hash_endpoint +0x52a/0x600 net/sctp/input.c:790 sctp_listen_start net/sctp/socket.c:8570 [en línea] sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625 __sys_listen_socket net/socket.c:1883 [en línea ] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [en línea] __se_sys_listen net/socket.c:1900 [en línea] __x64_sys_listen+0x5a/0x70 net/socket.c:1900 arco x64/ x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f24e46039b9 Código: 28 00 00 00 75 05 8 83 c4 28 c3 e8 91 1a 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:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032 RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: e46039b9 RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: Tener formato de archivo honorífico EVENT_FILE_FL_FREED Cuando se introdujo eventfs, se tuvo que tener especial cuidado para coordinar la liberación de los metadatos del archivo con los archivos que están expuestos al espacio del usuario. Los metadatos del archivo tendrían un recuento de referencias que se establece cuando se crea el archivo y se reducirían y liberarían después de que el último usuario que abrió el archivo lo cerró. Cuando se iban a liberar los metadatos del archivo, se establecería un indicador (EVENT_FILE_FL_FREED) para indicar que el archivo está liberado, y cualquier nueva referencia realizada (como nuevas aperturas o lecturas) fallaría ya que se marca como liberado. Esto permitió liberar otros metadatos después de establecer este indicador (bajo event_mutex). Todos los archivos que se crearon dinámicamente en el directorio de eventos tenían un puntero a los metadatos del archivo y llamarían a event_release() cuando se cerrara la última referencia al archivo de espacio de usuario. Este sería el momento en el que será seguro liberar los metadatos del archivo. Se creó un acceso directo para el archivo "formato". Es i_private apuntaría a la entrada "llamar" directamente y no a los metadatos del archivo. Esto se debe a que todos los archivos de formato son iguales para una misma "llamada", por lo que se pensó que no había motivo para diferenciarlos. Los otros archivos mantienen el estado (como "habilitar", "activar", etc.). Pero esto significaba que si el archivo desapareciera, el archivo "formateado" no lo sabría. Esto provocó una ejecución que podría desencadenarse a través de la prueba user_events (que crearía eventos dinámicos y los liberaría) y ejecutar un bucle que leería los archivos de formato user_events: En una ejecución de consola: # cd tools/testing/selftests/user_events # si bien es cierto; hacer ./ftrace_test; hecho Y en otra consola ejecute: # cd /sys/kernel/tracing/ # while true; hacer eventos de gato/eventos_usuario/__test_event/formato; done 2>/dev/null Con la comprobación de memoria de KASAN, se activaría un informe de error de use-after-free (que era un error real). Esto se debía a que el archivo de formato no estaba verificando el indicador de metadatos del archivo "EVENT_FILE_FL_FREED", por lo que accedería al evento al que apuntaban los metadatos del archivo después de que se liberara el evento. Después de la inspección, se encontró que hay otras ubicaciones que no marcaban el indicador EVENT_FILE_FL_FREED al acceder a trace_event_file. Agregue una nueva función auxiliar: event_file_file() que garantizará que event_mutex se mantenga y devolverá NULL si trace_event_file tiene establecido el indicador EVENT_FILE_FL_FREED. Haga que la primera referencia del puntero del archivo de estructura use event_file_file() y verifique NULL. Los usos posteriores aún pueden usar la función auxiliar event_file_data() si event_mutex aún se mantiene y no se liberó desde la llamada event_file_file().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: cs-amp-lib: soluciona el fallo del puntero NULL si efi.get_variable es NULL Llame a efi_rt_services_supported() para comprobar que efi.get_variable existe antes de llamarlo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: verificación de integridad del puntero NULL después de ext4_force_shutdown Caso de prueba: 2 subprocesos escriben datos breves en línea en un archivo. En ext4_page_mkwrite se convierten los datos en línea resultantes. El manejo de ext4_grp_locked_error con la descripción "mapa de bits de bloque y descriptor de bg inconsistentes: clústeres libres X vs Y" llama a ext4_force_shutdown. La conversión borra EXT4_STATE_MAY_INLINE_DATA pero falla para ext4_destroy_inline_data_nolock y ext4_mark_iloc_dirty debido a ext4_forced_shutdown. La restauración de datos en línea falla por el mismo motivo al no configurar EXT4_STATE_MAY_INLINE_DATA. Sin el indicador establecido, una ruta de proceso normal en ext4_da_write_end sigue intentando eliminar la referencia al puntero privado de la página que no se ha configurado. La solución llama al retorno anticipado con el error -EIO y el puntero a privado será NULL. Informe de falla de muestra: No se puede manejar la solicitud de paginación del kernel en la dirección virtual dfff800000000004 KASAN: null-ptr-deref en el rango [0x000000000000020-0x00000000000000027] Información de cancelación de memoria: ESR = 0x0000000096000005 EC = 0x25: DABT (actual EL), IL = 32 bits CONJUNTO = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: error de traducción de nivel 1 Información de cancelación de datos: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 dirección [dfff800000000004] entre los rangos de direcciones del usuario y del kernel Error interno: Ups: 0000000096000005 [#1] Módulos SMP PREEMPT vinculados en: CPU: 1 PID: 20274 Comm: syz-executor185 No está contaminado 6.9.0-rc7-syzkaller-gfda5695d692c #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT - SSBS BTYPE=--) pc: __block_commit_write+0x64/0x2b0 fs/buffer.c:2167 lr: __block_commit_write+0x3c/0x2b0 fs/buffer.c:2160 sp: ffff8000a1957600 x29: ffff8000a1957610 x28: 00000000 x27: ffff0000e30e34b0 x26: 0000000000000000 x25 : dfff800000000000 x24: dfff800000000000 x23: fffffdffc397c9e0 x22: 0000000000000020 x21: 00000000000000020 x20: 0000000000000040 x19: ffc397c9c0 x18: 1fffe000367bd196 x17: ffff80008eead000 x16: ffff80008ae89e3c x15: 00000000200000c0 x14: 1fffe0001cbe4e04 x13: 00000000000000000 x 12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9: 0000000000000000 x8: 0000000000000004 x7: 0000000000000000 x6: 0000000000000000 x5: fffffdffc397c9c0 x4: 00000000000000020 x3: 0000000000000020 x2: 000 0000000000040 x1: 0000000000000020 x0: fffffdffc397c9c0 Rastreo de llamadas: __block_commit_write+0x64/0x2b0 fs/buffer.c:2167 block_write_end+0xb4/0x104 fs/buffer .c:2253 ext4_da_do_write_end fs/ext4/inode.c:2955 [en línea] ext4_da_write_end+0x2c4/0xa40 fs/ext4/inode.c:3028 generic_perform_write+0x394/0x588 mm/filemap.c:3985 ext4_buffered_write_iter+0x2c0/0 x4ecfs/ ext4/file.c:299 ext4_file_write_iter+0x188/0x1780 call_write_iter include/linux/fs.h:2110 [en línea] new_sync_write fs/read_write.c:497 [en línea] vfs_write+0x968/0xc3c fs/read_write.c:590 ksys_write+ 0x15c/0x26c fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [en línea] __se_sys_write fs/read_write.c:652 [en línea] __arm64_sys_write+0x7c/0x90 fs/read_write.c:652 __invoke_syscall arch/arm64/ núcleo /syscall.c:34 [en línea] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133 do_el0_svc+0x48/0x58 arch/arm64/ kernel/syscall.c:152 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/ arm64/kernel/entry.S:598 Código: 97f85911 f94002da 91008356 d343fec8 (38796908) ---[ end trace 00000000000000000 ]--------- TRUNCADO ----------

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corrige la desreferencia del puntero NULL para el registro DTN en DCN401 Cuando los usuarios ejecutan el comando: cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log El siguiente puntero NULL ocurre la desreferencia: [+0.000003] ERROR: desreferencia del puntero NULL del kernel, dirección: NULL [+0.000005] #PF: búsqueda de instrucciones del supervisor en modo kernel [+0.000002] #PF: código_error(0x0010) - página no presente [+0.000002] PGD 0 P4D 0 [ +0.000004] Ups: 0010 [#1] PREEMPT SMP NOPTI [ +0.000003] RIP: 0010:0x0 [ +0.000008] Código: No se puede acceder a los bytes del código de operación en 0xffffffffffffffd6. [...] [ +0.000002] PKRU: 55555554 [ +0.000002] Seguimiento de llamadas: [ +0.000002] [ +0.000003] ? show_regs+0x65/0x70 [+0.000006]? __die+0x24/0x70 [ +0.000004] ? page_fault_oops+0x160/0x470 [+0.000006]? do_user_addr_fault+0x2b5/0x690 [+0.000003]? prb_read_valid+0x1c/0x30 [+0.000005]? exc_page_fault+0x8c/0x1a0 [+0.000005]? asm_exc_page_fault+0x27/0x30 [ +0.000012] dcn10_log_color_state+0xf9/0x510 [amdgpu] [ +0.000306] ? srso_alias_return_thunk+0x5/0xfbef5 [+0.000003]? vsnprintf+0x2fb/0x600 [ +0.000009] dcn10_log_hw_state+0xfd0/0xfe0 [amdgpu] [ +0.000218] ? __mod_memcg_lruvec_state+0xe8/0x170 [ +0.000008] ? srso_alias_return_thunk+0x5/0xfbef5 [+0.000002]? debug_smp_processor_id+0x17/0x20 [+0.000003]? srso_alias_return_thunk+0x5/0xfbef5 [+0.000002]? srso_alias_return_thunk+0x5/0xfbef5 [+0.000002]? set_ptes.isra.0+0x2b/0x90 [ +0.000004] ? srso_alias_return_thunk+0x5/0xfbef5 [+0.000002]? _raw_spin_unlock+0x19/0x40 [+0.000004]? srso_alias_return_thunk+0x5/0xfbef5 [+0.000002]? do_anonymous_page+0x337/0x700 [ +0.000004] dtn_log_read+0x82/0x120 [amdgpu] [ +0.000207] full_proxy_read+0x66/0x90 [ +0.000007] vfs_read+0xb0/0x340 [ +0.000005] ? __count_memcg_events+0x79/0xe0 [+0.000002]? srso_alias_return_thunk+0x5/0xfbef5 [+0.000003]? count_memcg_events.constprop.0+0x1e/0x40 [+0.000003]? handle_mm_fault+0xb2/0x370 [ +0.000003] ksys_read+0x6b/0xf0 [ +0.000004] __x64_sys_read+0x19/0x20 [ +0.000003] do_syscall_64+0x60/0x130 [ +0.000004] _64_after_hwframe+0x6e/0x76 [+0.000003] RIP: 0033:0x7fdf32f147e2 [...] Este error ocurre cuando el registro de color intenta leer la información de reasignación de gama de DCN401 que no está inicializada en dcn401_dpp_funcs, lo que conduce a una desreferencia del puntero nulo. Esta confirmación soluciona este problema agregando una protección adecuada para acceder a la devolución de llamada gamut_remap en caso de que el ASIC específico no haya implementado esta función.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: agregue una verificación NULL para 'afb' antes de eliminar la referencia en amdgpu_dm_plane_handle_cursor_update. Esta confirmación agrega una verificación nula para la variable 'afb' en la función amdgpu_dm_plane_handle_cursor_update. Anteriormente, se suponía que 'afb' era nulo, pero se usó más adelante en el código sin una verificación de nulo. Potencialmente, esto podría conducir a una desreferencia del puntero nulo. Corrige lo siguiente: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 error amdgpu_dm_plane_handle_cursor_update(): anteriormente asumimos que 'afb' podría ser nulo (consulte la línea 1252)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/admgpu: corrige la desreferenciación del contexto del puntero nulo Cuando el espacio de usuario establece un tipo ta no válido, el contexto del puntero estará vacío. Por lo tanto, es necesario verificar el contexto del puntero antes de usarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: corrige el desbordamiento en get_free_elt() "tracing_map->next_elt" en get_free_elt() corre el riesgo de desbordarse. Una vez que se desborda, aún se pueden insertar nuevos elementos en tracing_map aunque se haya alcanzado el número máximo de elementos (`max_elts`). Continuar insertando elementos después del desbordamiento podría dar como resultado que tracing_map contenga elementos "tracing_map->max_size", sin dejar entradas vacías. Si se intenta insertar un elemento en un tracing_map completo usando `__tracing_map_insert()`, se producirá un bucle infinito con la preferencia deshabilitada, lo que provocará un problema de bloqueo de la CPU. Solucione este problema evitando incrementos adicionales en "tracing_map->next_elt" una vez que llegue a "tracing_map->max_elt".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memcg: protege el acceso simultáneo a mem_cgroup_idr. el commit 73f576c04b94 ("mm: memcontrol: repara el error de creación de cgroup después de muchos trabajos pequeños") desacopla los ID de memcg del espacio de ID de CSS para reparar el cgroup. fracasos de la creación. Introdujo IDR para mantener el espacio de identificación de memcg. El IDR depende de mecanismos externos de sincronización para las modificaciones. Para mem_cgroup_idr, idr_alloc() e idr_replace() ocurren dentro de la devolución de llamada CSS y, por lo tanto, están protegidos a través de cgroup_mutex contra modificaciones simultáneas. Sin embargo, idr_remove() para mem_cgroup_idr no estaba protegido contra la concurrencia y se puede ejecutar simultáneamente para diferentes memcgs cuando alcanzan su referencia a cero. Arregla eso. Hemos estado viendo fallas del kernel basadas en list_lru con baja frecuencia en nuestra flota durante mucho tiempo. Estos fallos se produjeron en diferentes partes del código list_lru, incluidos list_lru_add(), list_lru_del() y el código de reparación. Tras una inspección más detallada, parecía que para un objeto determinado (dentry e inodo), el list_lru del super_block no tenía list_lru_one para el memcg de ese objeto. Las sospechas iniciales fueron que el objeto no estaba asignado a través de kmem_cache_alloc_lru() o de alguna manera memcg_list_lru_alloc() no pudo asignar list_lru_one() para un memcg pero devolvió el éxito. No se encontraron pruebas de estos casos. Mirando más profundamente, comenzamos a ver situaciones en las que la identificación de memcg válida no está presente en mem_cgroup_idr y, en algunos casos, varios memcg válidos tienen la misma identificación y mem_cgroup_idr apunta a uno de ellos. Entonces, la explicación más razonable es que estas situaciones pueden ocurrir debido a la ejecución entre múltiples llamadas idr_remove() o la ejecución entre idr_alloc()/idr_replace() e idr_remove(). Estas ejecuciones están provocando que varios memcgs adquieran el mismo ID y luego desconectar uno de ellos limpiaría list_lrus en el sistema para todos ellos. El acceso posterior desde otros memcgs a list_lru provoca bloqueos debido a que falta list_lru_one.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: core: verifique uartclk en busca de cero para evitar la división por cero. Llamar a ioctl TIOCSSERIAL con un baud_base no válido puede resultar en que uartclk sea cero, lo que resultará en un error de división por cero en uart_get_divisor (). La verificación de que uartclk sea cero en uart_set_info() debe realizarse antes de realizar otras configuraciones, ya que las llamadas posteriores a ioctl TIOCSSERIAL para el mismo puerto se verían afectadas si la verificación de uartclk se realizó donde se establece uartclk. Vaya: error de división: 0000 PREEMPT SMP KASAN PTI RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580) Seguimiento de llamadas: serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576 drivers /tty/serial/8250/8250_port.c:2589) serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502 drivers/tty/serial/8250/8250_port.c:2741) serial8250_set_termios (drivers/tty/serial/ 8250/8250_port.c:2862) uart_change_line_settings (./include/linux/spinlock.h:376 ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222) uart_port_startup (drivers/tty/ serial/serial_core.c:342) uart_startup (drivers/tty/serial/serial_core.c:368) uart_set_info (drivers/tty/serial/serial_core.c:1034) uart_set_info_user (drivers/tty/serial/serial_core.c:1059) tty_set_serial (drivers/tty/tty_io.c:2637) tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791) __x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907 fs /ioctl.c:893 fs/ioctl.c:893) do_syscall_64 (arch/x86/entry/common.c:52 (discriminador 1) arch/x86/entry/common.c:83 (discriminador 1)) Entry_SYSCALL_64_after_hwframe (arch /x86/entry/entry_64.S:130) Regla: agregar

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/client: corrige la desreferencia del puntero nulo en drm_client_modeset_probe En drm_client_modeset_probe(), el valor de retorno de drm_mode_duplicate() se asigna a modeset->mode, lo que conducirá a un posible puntero NULL desreferencia en caso de falla de drm_mode_duplicate(). Agregue una marca para evitar npd.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: elimine gso csum_start incorrecto y offset en virtio_net_hdr. Apriete las comprobaciones de csum_start y csum_offset en virtio_net_hdr_to_skb para paquetes GSO. La función ya comprueba que una suma de comprobación solicitada con VIRTIO_NET_HDR_F_NEEDS_CSUM esté en skb lineal. Pero para los paquetes OSG esto podría no ser válido para los segmentos posteriores a la segmentación. Syzkaller demostró alcanzar esta advertencia en skb_checksum_help offset = skb_checksum_start_offset(skb); ret = -EINVAL; if (WARN_ON_ONCE(offset >= skb_headlen(skb))) Al inyectar un paquete TSO: ADVERTENCIA: CPU: 1 PID: 3539 en net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0 ip_do_fragment+0x209/0x1b20 net/ipv4 /ip_output.c:774 ip_finish_output_gso net/ipv4/ip_output.c:279 [en línea] __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301 iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82 +0x2296 /0x2c70 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [en línea] ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4850 [en línea ] netdev_start_xmit include/linux/netdevice.h:4864 [en línea] xmit_one net/core/dev.c:3595 [en línea] dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611 __dev_queue_xmit+0x1b97/0x3c90 net/core/ dev.c:4261 paquete_snd net/packet/af_packet.c:3073 [en línea] La geometría del paquete de entrada incorrecto en tcp_gso_segment: [ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0 [ 52.003050] [ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244 [ 52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(tamaño=1552 tipo=3 segs=0)) [ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536 ip_summed=3 complete_sw=0 valid=0 nivel=0) Mitigar con una validación de entrada más estricta. csum_offset: para paquetes GSO, deduzca el valor correcto de gso_type. Esto ya está hecho para la OSU. Ampliarlo a TSO. Sea UFO: udp[46]_ufo_fragment ignora estos campos y siempre calcula la suma de comprobación en el software. csum_start: encontrar el desplazamiento real requiere analizar el encabezado de transporte. No agregue un analizador, utilice el análisis de segmentación existente. Gracias a SKB_GSO_DODGY, eso también detecta paquetes defectuosos que se descargan correctamente. Nuevamente pruebe tanto TSO como USO. No pruebe UFO por el motivo anterior y no pruebe la descarga del túnel UDP. Los paquetes OSG casi siempre son CHECKSUM_PARTIAL. Los paquetes USO pueden ser CHECKSUM_NONE desde el commit 10154dbded6d6 ("udp: Permitir transmisión GSO desde dispositivos sin descarga de suma de verificación"), pero aún así estos campos se inicializan correctamente en udp4_hwcsum/udp6_hwcsum_outgoing. Por lo tanto, no es necesario probar primero ip_summed == CHECKSUM_PARTIAL. Esto revisa una solución existente mencionada en la etiqueta Correcciones, que rompía paquetes pequeños con la descarga GSO, según lo detectado por kselftests.