Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> Squashfs: comprobar que el desplazamiento del bloque de metadatos está dentro del rango<br /> <br /> Syzkaller informa de un &amp;#39;fallo de protección general en squashfs_copy_data&amp;#39;<br /> <br /> Esto es causado en última instancia por una tabla de búsqueda de índices corrupta, que produce un desplazamiento de bloque de metadatos negativo.<br /> <br /> Esto se pasa posteriormente a squashfs_copy_data (a través de squashfs_read_metadata) donde el desplazamiento negativo causa un acceso fuera de límites.<br /> <br /> La solución es comprobar que el desplazamiento está dentro del rango en squashfs_read_metadata. Esto atrapará este y otros casos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ice: Corrección de fuga de memoria en ice_set_ringparam()<br /> <br /> En ice_set_ringparam, tx_rings y xdp_rings se asignan antes de rx_rings. Si la asignación de rx_rings falla, el código salta a la etiqueta done provocando una fuga tanto de tx_rings como de xdp_rings. Además, si la configuración de un anillo Rx individual falla durante el bucle, el código salta a la etiqueta free_tx, que libera tx_rings pero provoca una fuga de xdp_rings.<br /> <br /> Esto se corrige introduciendo una etiqueta free_xdp y actualizando las rutas de error para asegurar que tanto xdp_rings como tx_rings se liberen correctamente si la asignación o configuración de rx_rings falla.<br /> <br /> Probado solo en compilación. Problema encontrado utilizando una herramienta prototipo de análisis estático y revisión de código.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: bridge: corrige la desreferencia NULL de nd_tbl cuando IPv6 está deshabilitado<br /> <br /> Al arrancar con el parámetro &amp;#39;ipv6.disable=1&amp;#39;, el nd_tbl nunca se inicializa porque inet6_init() sale antes de que se llame a ndisc_init(), que es quien lo inicializa. Luego, si neigh_suppress está habilitado y un paquete ICMPv6 Neighbor Discovery llega al puente, br_do_suppress_nd() desreferenciará ipv6_stub-&amp;gt;nd_tbl, que es NULL, pasándolo a neigh_lookup(). Esto causa una desreferencia de puntero NULL del kernel.<br /> <br /> BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000268<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [...]<br /> RIP: 0010:neigh_lookup+0x16/0xe0<br /> [...]<br /> Rastro de Llamada:<br /> <br /> ? neigh_lookup+0x16/0xe0<br /> br_do_suppress_nd+0x160/0x290 [bridge]<br /> br_handle_frame_finish+0x500/0x620 [bridge]<br /> br_handle_frame+0x353/0x440 [bridge]<br /> __netif_receive_skb_core.constprop.0+0x298/0x1110<br /> __netif_receive_skb_one_core+0x3d/0xa0<br /> process_backlog+0xa0/0x140<br /> __napi_poll+0x2c/0x170<br /> net_rx_action+0x2c4/0x3a0<br /> handle_softirqs+0xd0/0x270<br /> do_softirq+0x3f/0x60<br /> <br /> Soluciona esto reemplazando la llamada a IS_ENABLED(IPV6) con ipv6_mod_enabled() en los llamadores. Esto es, en esencia, deshabilitar la supresión de NS/NA cuando IPv6 está deshabilitado.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> HID: Añadir protecciones HID_CLAIMED_INPUT en las retrollamadas de raw_event que las omiten<br /> <br /> En el commit 2ff5baa9b527 (&amp;#39;HID: appleir: Corregir posible desreferencia NULL en el manejo de eventos raw&amp;#39;), abordamos el hecho de que las retrollamadas de eventos raw pueden ocurrir incluso para un dispositivo HID que no ha sido &amp;#39;reclamado&amp;#39;, causando un fallo si se intentara conectar un dispositivo defectuoso al sistema.<br /> <br /> Corregir los controladores HID restantes en el árbol que olvidaron añadir esta misma comprobación para resolver el mismo problema.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bpf, arm64: Forzar alineación de 8 bytes para el búfer JIT para prevenir el desgarro atómico<br /> <br /> struct bpf_plt contiene un campo objetivo u64. Actualmente, el asignador JIT de BPF solicita una alineación de 4 bytes (sizeof(u32)) para el búfer JIT.<br /> <br /> Debido a que la dirección base del búfer JIT puede estar alineada a 4 bytes (p. ej., terminando en 0x4 o 0xc), la lógica de relleno relativo en build_plt() no logra asegurar que target caiga en un límite de 8 bytes.<br /> <br /> Esto lleva a dos problemas:<br /> 1. UBSAN informa advertencias de acceso desalineado al desreferenciar la estructura.<br /> 2. Más críticamente, target se actualiza concurrentemente a través de WRITE_ONCE() en bpf_arch_text_poke() mientras el código JIT&amp;#39;d ejecuta ldr. En arm64, las cargas/almacenamientos de 64 bits solo se garantiza que sean atómicos de copia única si están alineados a 64 bits. Un target desalineado arriesga una lectura desgarrada, haciendo que el JIT salte a una dirección corrupta.<br /> <br /> Solucione esto aumentando el requisito de alineación de asignación a 8 bytes (sizeof(u64)) en bpf_jit_binary_pack_alloc(). Esto ancla la base del búfer JIT a un límite de 8 bytes, permitiendo que las matemáticas de relleno relativo en build_plt() alineen correctamente el campo target.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> RDMA/ionic: Corrección de fuga de pila del kernel en ionic_create_cq()<br /> <br /> struct ionic_cq_resp resp {<br /> __u32 cqid[2]; // offset 0 - PARCIALMENTE ESTABLECIDO (ver abajo)<br /> __u8 udma_mask; // offset 8 - ESTABLECIDO (resp.udma_mask = vcq-&amp;gt;udma_mask)<br /> __u8 rsvd[7]; // offset 9 - NUNCA ESTABLECIDO &amp;lt;- FUGA<br /> };<br /> <br /> rsvd[7]: 7 bytes de memoria de pila fugados incondicionalmente.<br /> <br /> cqid[2]: El bucle en la línea 1256 itera sobre udma_idx pero omite los índices donde !(vcq-&amp;gt;udma_mask &amp;amp; BIT(udma_idx)). El array tiene 2 entradas pero udma_count podría ser 1, lo que significa que cqid[1] podría nunca ser escrito a través de ionic_create_cq_common(). Si udma_mask solo tiene el bit 0 establecido, cqid[1] (4 bytes) también se fuga. Así que potencialmente 11 bytes fugados.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netfilter: nf_tables: clonar conjunto solo al vaciar<br /> <br /> Syzbot con inyección de fallos activó una asignación de memoria fallida con<br /> GFP_KERNEL lo que resulta en un WARN splat:<br /> <br /> iter.err<br /> ADVERTENCIA: net/netfilter/nf_tables_api.c:845 en nft_map_deactivate+0x34e/0x3c0 net/netfilter/nf_tables_api.c:845, CPU#0: syz.0.17/5992<br /> Módulos enlazados:<br /> CPU: 0 UID: 0 PID: 5992 Comm: syz.0.17 No contaminado syzkaller #0 PREEMPT(full)<br /> Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026<br /> RIP: 0010:nft_map_deactivate+0x34e/0x3c0 net/netfilter/nf_tables_api.c:845<br /> Código: 8b 05 86 5a 4e 09 48 3b 84 24 a0 00 00 00 75 62 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 63 6d fa f7 90 &amp;lt;0f&amp;gt; 0b 90 43<br /> +80 7c 35 00 00 0f 85 23 fe ff ff e9 26 fe ff ff 89 d9<br /> RSP: 0018:ffffc900045af780 EFLAGS: 00010293<br /> RAX: ffffffff89ca45bd RBX: 00000000fffffff4 RCX: ffff888028111e40<br /> RDX: 0000000000000000 RSI: 00000000fffffff4 RDI: 0000000000000000<br /> RBP: ffffc900045af870 R08: 0000000000400dc0 R09: 00000000ffffffff<br /> R10: dffffc0000000000 R11: fffffbfff1d141db R12: ffffc900045af7e0<br /> R13: 1ffff920008b5f24 R14: dffffc0000000000 R15: ffffc900045af920<br /> FS: 000055557a6a5500(0000) GS:ffff888125496000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fb5ea271fc0 CR3: 000000003269e000 CR4: 00000000003526f0<br /> Rastro de llamada:<br /> <br /> __nft_release_table+0xceb/0x11f0 net/netfilter/nf_tables_api.c:12115<br /> nft_rcv_nl_event+0xc25/0xdb0 net/netfilter/nf_tables_api.c:12187<br /> notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85<br /> blocking_notifier_call_chain+0x6a/0x90 kernel/notifier.c:380<br /> netlink_release+0x123b/0x1ad0 net/netlink/af_netlink.c:761<br /> __sock_release net/socket.c:662 [inline]<br /> sock_close+0xc3/0x240 net/socket.c:1455<br /> <br /> Restringir la clonación del conjunto al comando de vaciado del conjunto en la fase de preparación.<br /> Añadir NFT_ITER_UPDATE_CLONE y usarlo para este propósito, actualizar los backends rbtree<br /> y pipapo para clonar el conjunto solo cuando se usa este tipo de iteración.<br /> <br /> En cuanto al tipo NFT_ITER_UPDATE existente, actualizar el backend pipapo para<br /> usar el clon de conjunto existente si está disponible, de lo contrario usar la representación<br /> de conjunto existente. Después de esta actualización, no hay necesidad de clonar un conjunto que<br /> está siendo eliminado, esto incluye el conjunto anónimo vinculado.<br /> <br /> Un enfoque alternativo a NFT_ITER_UPDATE_CLONE es añadir una interfaz .clone<br /> y llamarla desde la ruta de vaciado del conjunto.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gve: corrige la limpieza incorrecta del búfer en gve_tx_clean_pending_packets para QPL<br /> <br /> En el modo DQ-QPL, gve_tx_clean_pending_packets() utiliza incorrectamente la ruta de limpieza del búfer RDA. Itera num_bufs veces e intenta desmapear entradas en el array dma.<br /> <br /> Esto conduce a dos problemas:<br /> 1. El array dma comparte almacenamiento con tx_qpl_buf_ids (unión).<br /> Interpretar los IDs de búfer como direcciones DMA resulta en el intento de desmapear ubicaciones de memoria incorrectas.<br /> 2. num_bufs en modo QPL (contando bloques de 2K) puede exceder significativamente el tamaño del array dma, causando advertencias de acceso fuera de límites (el rastro a continuación es cómo notamos este problema).<br /> <br /> UBSAN: índice de array fuera de límites en<br /> drivers/net/ethernet/drivers/net/ethernet/google/gve/gve_tx_dqo.c:178:5 el índice 18 está fuera de<br /> rango para el tipo &amp;#39;dma_addr_t[18]&amp;#39; (también conocido como &amp;#39;unsigned long long[18]&amp;#39;)<br /> Cola de trabajo: gve gve_service_task [gve]<br /> Rastro de Llamada:<br /> <br /> dump_stack_lvl+0x33/0xa0<br /> __ubsan_handle_out_of_bounds+0xdc/0x110<br /> gve_tx_stop_ring_dqo+0x182/0x200 [gve]<br /> gve_close+0x1be/0x450 [gve]<br /> gve_reset+0x99/0x120 [gve]<br /> gve_service_task+0x61/0x100 [gve]<br /> process_scheduled_works+0x1e9/0x380<br /> <br /> Soluciona esto verificando correctamente el modo QPL y delegando a gve_free_tx_qpl_bufs() para reclamar los búferes.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> tracing: Corrección de WARN_ON en tracing_buffers_mmap_close<br /> <br /> Cuando un proceso hace fork, el proceso hijo copia los VMAs del padre pero el contador de referencias user_mapped no se incrementa. Como resultado, cuando tanto el proceso padre como el hijo terminan, tracing_buffers_mmap_close() se llama dos veces. En la segunda llamada, user_mapped ya es 0, lo que hace que la función devuelva -ENODEV y active un WARN_ON.<br /> <br /> Normalmente, esto no es un problema ya que la memoria está mapeada con VM_DONTCOPY establecido. Pero esto es solo una sugerencia, y la aplicación puede llamar a madvise(MADVISE_DOFORK) lo que restablece el flag VM_DONTCOPY. Cuando la aplicación hace eso, puede activar este problema al hacer fork.<br /> <br /> Se soluciona incrementando el contador de referencias user_mapped sin remapear las páginas en la función de callback &amp;#39;open&amp;#39; del VMA.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blktrace: fix __this_cpu_read/write in preemptible context<br /> <br /> tracing_record_cmdline() internally uses __this_cpu_read() and<br /> __this_cpu_write() on the per-CPU variable trace_cmdline_save, and<br /> trace_save_cmdline() explicitly asserts preemption is disabled via<br /> lockdep_assert_preemption_disabled(). These operations are only safe<br /> when preemption is off, as they were designed to be called from the<br /> scheduler context (probe_wakeup_sched_switch() / probe_wakeup()).<br /> <br /> __blk_add_trace() was calling tracing_record_cmdline(current) early in<br /> the blk_tracer path, before ring buffer reservation, from process<br /> context where preemption is fully enabled. This triggers the following<br /> using blktests/blktrace/002:<br /> <br /> blktrace/002 (blktrace ftrace corruption with sysfs trace) [failed]<br /> runtime 0.367s ... 0.437s<br /> something found in dmesg:<br /> [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33<br /> [ 81.239580] null_blk: disk nullb1 created<br /> [ 81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516<br /> [ 81.362842] caller is tracing_record_cmdline+0x10/0x40<br /> [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full)<br /> [ 81.362877] Tainted: [N]=TEST<br /> [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014<br /> [ 81.362881] Call Trace:<br /> [ 81.362884] <br /> [ 81.362886] dump_stack_lvl+0x8d/0xb0<br /> ...<br /> (See &amp;#39;/mnt/sda/blktests/results/nodev/blktrace/002.dmesg&amp;#39; for the entire message)<br /> <br /> [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33<br /> [ 81.239580] null_blk: disk nullb1 created<br /> [ 81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516<br /> [ 81.362842] caller is tracing_record_cmdline+0x10/0x40<br /> [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full)<br /> [ 81.362877] Tainted: [N]=TEST<br /> [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014<br /> [ 81.362881] Call Trace:<br /> [ 81.362884] <br /> [ 81.362886] dump_stack_lvl+0x8d/0xb0<br /> [ 81.362895] check_preemption_disabled+0xce/0xe0<br /> [ 81.362902] tracing_record_cmdline+0x10/0x40<br /> [ 81.362923] __blk_add_trace+0x307/0x5d0<br /> [ 81.362934] ? lock_acquire+0xe0/0x300<br /> [ 81.362940] ? iov_iter_extract_pages+0x101/0xa30<br /> [ 81.362959] blk_add_trace_bio+0x106/0x1e0<br /> [ 81.362968] submit_bio_noacct_nocheck+0x24b/0x3a0<br /> [ 81.362979] ? lockdep_init_map_type+0x58/0x260<br /> [ 81.362988] submit_bio_wait+0x56/0x90<br /> [ 81.363009] __blkdev_direct_IO_simple+0x16c/0x250<br /> [ 81.363026] ? __pfx_submit_bio_wait_endio+0x10/0x10<br /> [ 81.363038] ? rcu_read_lock_any_held+0x73/0xa0<br /> [ 81.363051] blkdev_read_iter+0xc1/0x140<br /> [ 81.363059] vfs_read+0x20b/0x330<br /> [ 81.363083] ksys_read+0x67/0xe0<br /> [ 81.363090] do_syscall_64+0xbf/0xf00<br /> [ 81.363102] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 81.363106] RIP: 0033:0x7f281906029d<br /> [ 81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec<br /> [ 81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> [ 81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d<br /> [ 81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000<br /> [ 81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000<br /> [ 81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000<br /> [ 81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a<br /> [ 81.363142] <br /> <br /> The same BUG fires from blk_add_trace_plug(), blk_add_trace_unplug(),<br /> and blk_add_trace_rq() paths as well.<br /> <br /> The purpose of tracin<br /> ---truncated---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ice: cambiar frag_size de XDP RxQ de la longitud de escritura DMA a xdp.frame_sz<br /> <br /> El único usuario del campo frag_size en la información de XDP RxQ es bpf_xdp_frags_increase_tail(). Claramente espera el tamaño completo del búfer en lugar del tamaño de escritura DMA. Diferentes suposiciones en la configuración del controlador ice llevan a un tailroom negativo.<br /> <br /> Esto permite activar un pánico del kernel, al usar la prueba xskxceiver XDP_ADJUST_TAIL_GROW_MULTI_BUFF y cambiar el tamaño del paquete a 6912 y el desplazamiento solicitado a un valor enorme, por ejemplo, XSK_UMEM__MAX_FRAME_SIZE * 100.<br /> <br /> Debido a otras peculiaridades de la configuración ZC en ice, no se observa pánico en modo ZC, pero el crecimiento del tailroom sigue fallando cuando no debería.<br /> <br /> Usar el tamaño real del búfer de la cola de llenado en lugar del tamaño de escritura DMA en la información de XDP RxQ. Corregir el modo ZC también usando la nueva función auxiliar.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: act_ife: Corregir el comportamiento de actualización de la metalista<br /> <br /> Siempre que una acción ife replace cambia la metalista, en lugar de reemplazar los datos antiguos en la metalista, el código ife actual está añadiendo los nuevos metadatos. Además de ser un comportamiento inapropiado, esto puede llevar a una adición ilimitada de metadatos a la metalista, lo que podría causar un error de fuera de límites al ejecutar la operación de codificación:<br /> <br /> [ 138.423369][ C1] ==================================================================<br /> [ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ife_tlv_meta_encode (net/ife/ife.c:168)<br /> [ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ife_out_out_bou/255<br /> [ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ife_out_out_bou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full)<br /> [ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> [ 138.425800][ C1] Call Trace:<br /> [ 138.425804][ C1] <br /> [ 138.425808][ C1] dump_stack_lvl (lib/dump_stack.c:122)<br /> [ 138.425828][ C1] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)<br /> [ 138.425839][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 138.425844][ C1] ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1))<br /> [ 138.425853][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168)<br /> [ 138.425859][ C1] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597)<br /> [ 138.425868][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168)<br /> [ 138.425878][ C1] kasan_check_range (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1))<br /> [ 138.425884][ C1] __asan_memset (mm/kasan/shadow.c:84 (discriminator 2))<br /> [ 138.425889][ C1] ife_tlv_meta_encode (net/ife/ife.c:168)<br /> [ 138.425893][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:171)<br /> [ 138.425898][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 138.425903][ C1] ife_encode_meta_u16 (net/sched/act_ife.c:57)<br /> [ 138.425910][ C1] ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114)<br /> [ 138.425916][ C1] ? __asan_memcpy (mm/kasan/shadow.c:105 (discriminator 3))<br /> [ 138.425921][ C1] ? __pfx_ife_encode_meta_u16 (net/sched/act_ife.c:45)<br /> [ 138.425927][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 138.425931][ C1] tcf_ife_act (net/sched/act_ife.c:847 net/sched/act_ife.c:879)<br /> <br /> Para resolver este problema, corregir el comportamiento de reemplazo añadiendo la metalista a la estructura de datos ife rcu.