Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: se corrige slab-use-after-free debido al puntero colgante dqi_priv Al montar ocfs2 y luego volver a montarlo como de solo lectura, se produce un slab-use-after-free después de que el usuario usa una llamada al sistema a quota_getnextquota. Específicamente, sb_dqinfo(sb, type)->dqi_priv es el puntero colgante. Durante el proceso de remontaje, el puntero dqi_priv se libera pero nunca se establece como nulo, dejándolo para que se pueda acceder a él. Además, la opción de solo lectura para remontaje establece el indicador DQUOT_SUSPENDED en lugar de establecer los indicadores DQUOT_USAGE_ENABLED. Además, más adelante en el proceso de obtención de la siguiente cuota, se llama a la función ocfs2_get_next_id y solo verifica los indicadores de uso de cuota y no los indicadores de cuota suspendida. Para solucionar esto, establezco dqi_priv en nulo cuando se libera después de volver a montar con solo lectura y pongo una marca de verificación para DQUOT_SUSPENDED en ocfs2_get_next_id. [akpm@linux-foundation.org: limpiezas de estilo de codificación]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: seq: oss: Se corrigen las ejecuciones al procesar mensajes SysEx El secuenciador OSS gestiona los mensajes SysEx divididos en paquetes de 6 bytes y la capa OSS del secuenciador ALSA intenta combinarlos. Almacena los datos en el búfer interno y este acceso es acelerado a partir de ahora, lo que puede llevar al acceso fuera de los límites. Como solución temporal, introduzca un mutex para serializar el proceso de los paquetes de mensajes SysEx.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Se corrige un error en el cierre de fd después de desvincular Si el espacio de usuario mantiene abierto un fd, desvincula el dispositivo y luego lo cierra, el controlador no debería intentar acceder al hardware. Protéjalo usando drm_dev_enter()/drm_dev_exit(). Esto corrige el siguiente error de página: <6> [IGT] xe_wedged: saliendo, ret=98 <1> ERROR: no se puede gestionar el error de página para la dirección: ffffc901bc5e508c <1> #PF: acceso de lectura del supervisor en modo kernel <1> #PF: error_code(0x0000) - not-present page ... <4> xe_lrc_update_timestamp+0x1c/0xd0 [xe] <4> xe_exec_queue_update_run_ticks+0x50/0xb0 [xe] <4> xe_exec_queue_fini+0x16/0xb0 [xe] <4> __guc_exec_queue_fini_async+0xc4/0x190 [xe] <4> guc_exec_queue_fini_async+0xa0/0xe0 [xe] <4> guc_exec_queue_fini+0x23/0x40 [xe] <4> xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> xe_file_close+0xd4/0x1a0 [xe] <4> drm_file_free+0x210/0x280 [drm] <4> drm_close_helper.isra.0+0x6d/0x80 [drm] <4> drm_release_noglobal+0x20/0x90 [drm] (seleccionado de el commit 4ca1fd418338d4d135428a0eb1e16e3b3ce17ee8)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/siw: eliminar el enlace directo a net_device No administrar un enlace directo por dispositivo a net_device. Confíe en la administración de net_device de ib_devices asociada, sin duplicar el esfuerzo localmente. Un enlace local mal administrado a net_device estaba causando una excepción 'KASAN: slab-use-after-free' durante la llamada siw_query_port().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/kmemleak: se corrige la función inactiva llamada desde un contexto no válido en el mensaje de impresión Se soluciona un error en el kernel que activa una advertencia de "función inactiva llamada desde un contexto no válido" cuando se imprime /sys/kernel/debug/kmemleak en condiciones específicas: - CONFIG_PREEMPT_RT=y - Establezca SELinux como el LSM para el sistema - Establezca kptr_restrict en 1 - el búfer de kmemleak contiene al menos un elemento ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 136, name: cat preempt_count: 1, expected: 0 Profundidad de anidación de RCU: 2, expected: 2 6 bloqueos mantenidos por cat/136: #0: ffff32e64bcbf950 (&p->bloqueo){+.+.}-{3:3}, en: seq_read_iter+0xb8/0xe30 #1: ffffafe6aaa9dea0 (scan_mutex){+.+.}-{3:3}, en: kmemleak_seq_start+0x34/0x128 #3: ffff32e6546b1cd0 (&object->bloqueo){....}-{2:2}, en: kmemleak_seq_show+0x3c/0x1e0 #4: ffffafe6aa8d8560 (rcu_lectura_bloqueo){....}-{1:2}, en: has_ns_capability_noaudit+0x8/0x1b0 #5: ffffafe6aabbc0f8 (notif_bloqueo){+.+.}-{2:2}, en: avc_compute_av+0xc4/0x3d0 marca de evento de irq: 136660 hardirqs habilitados por última vez en (136659): [] _raw_spin_unlock_irqrestore+0xa8/0xd8 hardirqs deshabilitados por última vez en (136660): [] _raw_spin_lock_irqsave+0x8c/0xb0 softirqs habilitados por última vez en (0): [] copy_process+0x11d8/0x3df8 softirqs deshabilitados por última vez en (0): [<0000000000000000>] 0x0 Preempción deshabilitada en: [] kmemleak_seq_show+0x3c/0x1e0 CPU: 1 UID: 0 PID: 136 Comm: cat Contaminado: GE 6.11.0-rt7+ #34 Contaminado: [E]=UNSIGNED_MODULE Nombre del hardware: linux,dummy-virt (DT) Rastreo de llamadas: dump_backtrace+0xa0/0x128 show_stack+0x1c/0x30 dump_stack_lvl+0xe8/0x198 dump_stack+0x18/0x20 rt_spin_lock+0x8c/0x1a8 avc_perm_nonode+0xa0/0x150 cred_has_capability.isra.0+0x118/0x218 selinux_capable+0x50/0x80 security_capable+0x7c/0xd0 has_ns_capability_noaudit+0x94/0x1b0 has_capability_noaudit+0x20/0x30 puntero_restringido+0x21c/0x4b0 puntero+0x298/0x760 vsnprintf+0x330/0xf70 seq_printf+0x178/0x218 impresión_sin_referencia+0x1a4/0x2d0 kmemleak_seq_show+0xd0/0x1e0 seq_read_iter+0x354/0xe30 seq_read+0x250/0x378 lectura_proxy_completa+0xd8/0x148 vfs_read+0x190/0x918 ksys_read+0xf0/0x1e0 __arm64_sys_read+0x70/0xa8 %pS y %pK, en la misma línea de seguimiento inverso, son redundantes, y %pS puede anular el servicio %pK en ciertos contextos. %pS solo ya proporciona la información necesaria, y si no puede resolver el símbolo, vuelve a imprimir la dirección sin formato anulando la intención original detrás de %pK. Además, %pK requiere una verificación de privilegios CAP_SYSLOG aplicada a través del LSM, que puede activar una advertencia de "función inactiva llamada desde un contexto no válido" en kernels RT_PREEMPT cuando la verificación ocurre en un contexto atómico. Este problema también puede afectar a otros LSM. Este cambio evita la verificación de privilegios innecesaria y resuelve la advertencia de función inactiva sin ninguna pérdida de información.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: hugetlb: recuento compartido de la tabla de páginas PMD independiente El recuento de referencias de folio puede aumentar inesperadamente a través de try_get_folio() por un llamador como split_huge_pages. En huge_pmd_unshare(), usamos el recuento de referencias para verificar si una tabla de páginas pmd está compartida. La comprobación es incorrecta si el llamador anterior aumenta el refcount, y esto puede provocar una fuga de la tabla de páginas: ERROR: Estado de página incorrecto en proceso sh pfn:109324 página: refcount:0 mapcount:0 mapping:0000000000000000 índice:0x66 pfn:0x109324 indicadores: 0x17ffff800000000(nodo=0|zona=2|lastcpupid=0xfffff) tipo_página: f2(tabla) sin procesar: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 sin procesar: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000 página volcada porque: mapcount distinto de cero ... CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: cargado Contaminado: GB 6.13.0-rc2master+ #7 Contaminado: [B]=BAD_PAGE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 dump_stack+0x18/0x28 bad_page+0x8c/0x130 free_page_is_bad_report+0xa4/0xb0 free_unref_page+0x3cc/0x620 __folio_put+0xf4/0x158 split_huge_pages_all+0x1e0/0x3e8 split_huge_pages_write+0x25c/0x2d8 full_proxy_write+0x64/0xd8 vfs_write+0xcc/0x280 ksys_write+0x70/0x110 __arm64_sys_write+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198 El problema puede ser provocado por damon, offline_page, page_idle, etc., que aumentarán el recuento de referencias de la tabla de páginas. 1. La tabla de páginas en sí se descartará después de informar el "recuento de mapas distinto de cero". 2. La página HugeTLB mapeada por la tabla de páginas no se libera ya que tratamos la tabla de páginas como compartida y una tabla de páginas compartida no se desasignará. Arréglelo introduciendo un recuento de páginas compartidas de tabla de páginas PMD independiente. Como se describe en el comentario, pt_index/pt_mm/pt_frag_refcount se utilizan para s390 gmap, x86 pgds y powerpc, pt_share_count se utiliza para x86/arm64/riscv pmds, por lo que podemos reutilizar el campo como pt_share_count.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: se corrige pérdida de memoria en tcp_conn_request() Si inet_csk_reqsk_queue_hash_add() devuelve falso, tcp_conn_request() devolverá sin liberar la memoria dst, que se asignó en af_ops->route_req. Aquí está la pila de kmemleak: objeto sin referencia 0xffff8881198631c0 (tamaño 240): comm "softirq", pid 0, jiffies 4299266571 (edad 1802.392s) volcado hexadecimal (primeros 32 bytes): 00 10 9b 03 81 88 ff ff 80 98 da bc ff ff ff ff ff ................ 81 55 18 bb ff ff ff ff ff 00 00 00 00 00 00 00 00 .U.............. backtrace: [] kmem_cache_alloc+0x60c/0xa80 [] dst_alloc+0x55/0x250 [] rt_dst_alloc+0x46/0x1d0 [] __mkroute_output+0x29a/0xa50 [] ip_route_output_key_hash+0x10b/0x240 [] ip_route_output_flow+0x1d/0x90 [] inet_csk_route_req+0x2c5/0x500 [] tcp_conn_request+0x691/0x12c0 [] tcp_rcv_state_process+0x3c8/0x11b0 [] tcp_v4_do_rcv+0x156/0x3b0 [] tcp_v4_rcv+0x1cf8/0x1d80 [] ip_protocol_deliver_rcu+0xf6/0x360 [] ip_local_deliver_finish+0xe6/0x1e0 [] ip_local_deliver+0xee/0x360 [] ip_rcv+0xad/0x2f0 [] __netif_receive_skb_one_core+0x123/0x140 Llame a dst_release() para liberar la memoria dst cuando inet_csk_reqsk_queue_hash_add() devuelva falso en tcp_conn_request().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: corrige el desbordamiento de opciones TCP. Syzbot informó el siguiente splat: Oops: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x000000000000008-0x000000000000000f] CPU: 1 UID: 0 PID: 5836 Comm: sshd No contaminado 6.13.0-rc3-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/11/2024 RIP: 0010:_compound_head include/linux/page-flags.h:242 [en línea] RIP: 0010:put_page+0x23/0x260 include/linux/mm.h:1552 Código: 90 90 90 90 90 90 90 55 41 57 41 56 53 49 89 fe 48 bd 00 00 00 00 00 fc ff df e8 f8 5e 12 f8 49 8d 5e 08 48 89 d8 48 c1 e8 03 <80> 3c 28 00 74 08 48 89 df e8 8f c7 78 f8 48 8b 1b 48 89 de 48 83 RSP: 0000:ffffc90003916c90 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 00000000000000008 RCX: ffff888030458000 RDX: 00000000000000100 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff898ca81d R09: 1ffff110054414ac R10: dffffc0000000000 R11: ffffed10054414ad R12: 0000000000000007 R13: ffff88802a20a542 R14: 0000000000000000 R15: 00000000000000000 FS: 00007f34f496e800(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9d6ec9ec28 CR3: 000000004d260000 CR4: 00000000003526f0 DR0: 000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: skb_page_unref include/linux/skbuff_ref.h:43 [inline] __skb_frag_unref include/linux/skbuff_ref.h:56 [inline] skb_release_data+0x483/0x8a0 net/core/skbuff.c:1119 skb_release_all net/core/skbuff.c:1190 [inline] __kfree_skb+0x55/0x70 net/core/skbuff.c:1204 tcp_clean_rtx_queue net/ipv4/tcp_input.c:3436 [inline] tcp_ack+0x2442/0x6bc0 net/ipv4/tcp_input.c:4032 tcp_rcv_state_process+0x8eb/0x44e0 net/ipv4/tcp_input.c:6805 tcp_v4_do_rcv+0x77d/0xc70 net/ipv4/tcp_ipv4.c:1939 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5672 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5785 process_backlog+0x662/0x15b0 net/core/dev.c:6117 __napi_poll+0xcb/0x490 net/core/dev.c:6883 napi_poll net/core/dev.c:6952 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:7074 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __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 [inline] sysvec_apic_timer_interrupt+0x57/0xc0 arch/x86/kernel/apic/apic.c:1049 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0033:0x7f34f4519ad5 Code: 85 d2 74 0d 0f 10 02 48 8d 54 24 20 0f 11 44 24 20 64 8b 04 25 18 00 00 00 85 c0 75 27 41 b8 08 00 00 00 b8 0f 01 00 00 0f 05 <48> 3d 00 f0 ff ff 76 75 48 8b 15 24 73 0d 00 f7 d8 64 89 02 48 83 RSP: 002b:00007ffec5b32ce0 EFLAGS: 00000246 RAX: 0000000000000001 RBX: 00000000000668a0 RCX: 00007f34f4519ad5 RDX: 00007ffec5b32d00 RSI: 0000000000000004 RDI: 0000564f4bc6cae0 RBP: 0000564f4bc6b5a0 R08: 0000000000000008 R09: 0000000000000000 R10: 00007ffec5b32de8 R11: 0000000000000246 R12: 0000564f48ea8aa4 R13: 0000000000000001 R14: 0000564f48ea93e8 R15: 00007ffec5b32d68 Eric notó una probable corrupción de shinfo->nr_frags, que de hecho ocurre. La causa raíz es un cálculo defectuoso de la longitud de la opción MPTCP en algunas circunstancias: la opción ADD_ADDR debería ser mutuamente excluyente con DSS desde la confirmación culpable. Aún así, mptcp_established_options_add_addr() intenta establecer la información ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: vmscan: tiene en cuenta las páginas libres para evitar un bucle infinito en throttle_direct_reclaim() La tarea a veces continúa en bucle en throttle_direct_reclaim() porque allow_direct_reclaim(pgdat) sigue devolviendo falso. #0 [ffff80002cb6f8d0] __switch_to en ffff8000080095ac #1 [ffff80002cb6f900] __schedule en ffff800008abbd1c #2 [ffff80002cb6f990] schedule en ffff800008abc50c #3 [ffff80002cb6f9b0] throttle_direct_reclaim en ffff800008273550 #4 [ffff80002cb6fa20] try_to_free_pages en ffff800008277b68 #5 [ffff80002cb6fae0] __alloc_pages_nodemask en ffff8000082c4660 #6 [ffff80002cb6fc50] alloc_pages_vma en ffff8000082e4a98 #7 [ffff80002cb6fca0] do_anonymous_page en ffff80000829f5a8 #8 [ffff80002cb6fce0] __handle_mm_fault en ffff8000082a5974 #9 [ffff80002cb6fd90] handle_mm_fault en ffff8000082a5bd4 En este punto, el pgdat contiene las siguientes dos zonas: NODO: 4 ZONA: 0 DIRECCIÓN: ffff00817fffe540 NOMBRE: "DMA32" TAMAÑO: 20480 MÍN./BAJO/ALTO: 11/28/45 ESTADÍSTICA DE VM: NR_PÁGINAS_LIBRES: 359 NR_ZONA_INACTIVA_ANON: 18813 NR_ZONA_ACTIVA_ANON: 0 NR_ZONA_ARCHIVO_INACTIVO: 50 NR_ZONA_ARCHIVO_ACTIVO: 0 NR_ZONA_UNEVICTABLE: 0 NR_ZONA_ESCRITURA_PENDIENTE: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_PÁGINAS_CMA_LIBRES: 0 NODO: 4 ZONA: 1 DIRECCIÓN: ffff00817fffec00 NOMBRE: "Normal" TAMAÑO: 8454144 PRESENTE: 98304 MÍN./BAJO/ALTO: 68/166/264 ESTADÍSTICO_VM: NR_PÁGINAS_LIBRES: 146 NR_ZONE_INACTIVE_ANON: 94668 NR_ZONE_ACTIVE_ANON: 3 NR_ZONE_INACTIVE_FILE: 735 NR_ZONE_ACTIVE_FILE: 78 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 En allow_direct_reclaim(), mientras se procesa ZONE_DMA32, la suma de páginas inactivas/activas respaldadas por archivos calculada en zone_reclaimable_pages() en función del resultado de zone_page_state_snapshot() es cero. Además, dado que este sistema carece de intercambio, se omite el cálculo de páginas anónimas inactivas/activas. crash> p nr_swap_pages nr_swap_pages = $1937 = { counter = 0 } Como resultado, ZONE_DMA32 se considera irrecuperable y se omite, pasando al procesamiento de la siguiente zona, ZONE_NORMAL, a pesar de que ZONE_DMA32 tiene páginas libres que exceden significativamente la marca de agua alta. El problema es que pgdat->kswapd_failures no se ha incrementado. crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures $1935 = 0x0 Esto se debe a que el nodo se considera equilibrado. La lógica de equilibrio de nodos en balance_pgdat() evalúa todas las zonas colectivamente. Si una o más zonas (por ejemplo, ZONE_DMA32) tienen suficientes páginas libres para cumplir con sus marcas de agua, todo el nodo se considera equilibrado. Esto hace que balance_pgdat() salga antes de incrementar kswapd_failures, ya que considera que el estado general de la memoria es aceptable, aunque algunas zonas (como ZONE_NORMAL) permanezcan bajo una presión significativa. El parche garantiza que zone_reclaimable_pages() incluya páginas libres (NR_FREE_PAGES) en su cálculo cuando no haya otras páginas recuperables disponibles (por ejemplo, páginas anónimas o respaldadas por archivos). Este cambio evita que zonas como ZONE_DMA32, que tienen suficientes páginas libres, se consideren por error no recuperables. Al hacerlo, el parche garantiza un equilibrio adecuado de los nodos, evita enmascarar la presión en otras zonas como ZONE_NORMAL y evita bucles infinitos en throttle_direct_reclaim() causados por allow_direct_reclaim(pgdat) que devuelve falso repetidamente. El núcleo se cuelga debido a una tarea atascada en throttle_direct_reclaim(), causada por un nodo que se considera incorrectamente equilibrado a pesar de la presión en ciertas zonas, como ZONE_NORMAL. Este problema surge de zone_reclaimable_pages ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Omitir reglas de restauración de TC para vport rep sin indicador cargado Durante la descarga del controlador, se llama a unregister_netdev después de descargar vport rep. Por lo tanto, mlx5e_rep_priv ya está liberado al intentar obtener rpriv->netdev, o recorrer rpriv->tc_ht, lo que da como resultado un use-after-free. Por lo tanto, agregue la verificación para asegurarse de acceder a los datos de vport rep que aún están cargados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netrom: comprobar la longitud del búfer antes de acceder a él Syzkaller informa de un valor no inicializado leído desde ax25cmp al enviar un mensaje sin formato a través de la implementación de ieee802154. ======================================================= ERROR: KMSAN: valor no inicializado en ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119 ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119 nr_dev_get+0x20e/0x450 net/netrom/nr_route.c:601 nr_route_frame+0x1a2/0xfc0 net/netrom/nr_route.c:774 nr_xmit+0x5a/0x1c0 net/netrom/nr_dev.c:144 __netdev_start_xmit include/linux/netdevice.h:4940 [en línea] netdev_start_xmit include/linux/netdevice.h:4954 [en línea] xmit_one net/core/dev.c:3548 [en línea] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [en línea] raw_sendmsg+0x654/0xc10 net/ieee802154/socket.c:299 ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [en línea] __do_sys_sendmsg net/socket.c:2676 [en línea] __se_sys_sendmsg net/socket.c:2674 [en línea] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Se creó un unit en: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [en línea] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [en línea] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2780 sock_alloc_send_skb include/net/sock.h:1884 [en línea] raw_sendmsg+0x36d/0xc10 net/ieee802154/socket.c:282 ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [en línea] __do_sys_sendmsg net/socket.c:2676 [en línea] __se_sys_sendmsg net/socket.c:2674 [en línea] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 5037 Comm: syz-executor166 No contaminado 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 ======================================================= Este problema se produce porque el búfer skb es demasiado pequeño, y su asignación actual está alineada. Esto oculta un problema real, que es que nr_route_frame no valida el tamaño del búfer antes de usarlo. Solucione este problema comprobando skb->len antes de acceder a cualquier campo en skb->data. Encontrado por Linux Verification Center (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_set_hash: lectura atómica no alineada en la estructura nft_set_ext El acceso al campo genmask en la estructura nft_set_ext da como resultado una lectura atómica no alineada: [72.130109] No se puede gestionar la solicitud de paginación del kernel en la dirección virtual ffff0000c2bb708c [72.131036] Información de cancelación de memoria: [72.131213] ESR = 0x0000000096000021 [72.131446] EC = 0x25: DABT (EL actual), IL = 32 bits [72.132209] SET = 0, FnV = 0 [72.133216] EA = 0, S1PTW = 0 [ 72.134080] FSC = 0x21: error de alineación [ 72.135593] Información de cancelación de datos: [ 72.137194] ISV = 0, ISS = 0x00000021, ISS2 = 0x00000000 [ 72.142351] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 72.145989] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 72.150115] swapper pgtable: páginas de 4k, VA de 48 bits, pgdp=0000000237d27000 [ 72.154893] [ffff0000c2bb708c] pgd=0000000000000000, p4d=180000023ffff403, pud=180000023f84b403, pmd=180000023f835403, +pte=0068000102bb7707 [ 72.163021] Error interno: Oops: 0000000096000021 [#1] SMP [...] [ 72.170041] CPU: 7 UID: 0 PID: 54 Comm: kworker/7:0 Contaminado: GE 6.13.0-rc3+ #2 [ 72.170509] Contaminado: [E]=UNSIGNED_MODULE [ 72.170720] Nombre del hardware: QEMU QEMU Virtual Máquina, BIOS edk2-stable202302-for-qemu 03/01/2023 [ 72.171192] Cola de trabajo: events_power_efficient nft_rhash_gc [nf_tables] [ 72.171552] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 72.171915] pc : nft_rhash_gc+0x200/0x2d8 [nf_tables] [ 72.172166] lr : nft_rhash_gc+0x128/0x2d8 [nf_tables] [ 72.172546] sp : ffff800081f2bce0 [ 72.172724] x29: ffff800081f2bd40 x28: ffff0000c2bb708c x27: 0000000000000038 [ 72.173078] x26: ffff0000c6780ef0 x25: ffff0000c643df00 x24: ffff0000c6778f78 [ 72.173431] x23: 000000000000001a x22: ffff0000c4b1f000 x21: ffff0000c6780f78 [ 72.173782] x20: ffff0000c2bb70dc x19: ffff0000c2bb7080 x18: 0000000000000000 [ 72.174135] x17: ffff0000c0a4e1c0 x16: 0000000000003000 x15: 0000ac26d173b978 [ 72.174485] x14: ffffffffffffffffff x13: 0000000000000030 x12: ffff0000c6780ef0 [ 72.174841] x11: 000000000000000 x10: ffff800081f2bcf8 x9 : ffff0000c3000000 [ 72.175193] x8 : 00000000000004be x7 : 0000000000000000 x6 : 0000000000000000 [ 72.175544] x5 : 0000000000000040 x4 : ffff0000c3000010 x3 : 0000000000000000 [ 72.175871] x2 : 0000000000003a98 x1 : ffff0000c2bb708c x0 : 0000000000000004 [ 72.176207] Rastreo de llamadas: [ 72.176316] nft_rhash_gc+0x200/0x2d8 [nf_tables] (P) [ 72.176653] process_one_work+0x178/0x3d0 [ 72.176831] worker_thread+0x200/0x3f0 [ 72.176995] kthread+0xe8/0xf8 [ 72.177130] ret_from_fork+0x10/0x20 [ 72.177289] Código: 54fff984 d503201f d2800080 91003261 (f820303f) [ 72.177557] ---[ fin de seguimiento 0000000000000000 ]--- Alinear estructura nft_set_ext al tamaño de palabra para abordar esto y documentarlo. pahole informa que esto aumenta el tamaño de los elementos para rhash y pipapo en 8 bytes en x86_64.