Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") eliminó accidentalmente la parte crítica del commit c730fce7c70c ("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), lo que provocaba la reaparición de pánicos de kernel intermitentes en el programa on_switch() de perf, por ejemplo. Restablezca la corrección y añada un comentario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rpl: Se corrige el problema de use-after-free en rpl_do_srh_inline(). Ejecutar lwt_dst_cache_ref_loop.sh en autoprueba con KASAN activa el splat debajo de [0]. rpl_do_srh_inline() recupera ipv6_hdr(skb) y accede a él después de skb_cow_head(), lo cual es ilegal, ya que la cabecera podría liberarse en ese momento. Para solucionarlo, convertimos oldhdr en una estructura local en lugar de un puntero. [0]: [root@fedora net]# ./lwt_dst_cache_ref_loop.sh ... TEST: rpl (input) [ 57.631529] ================================================================== BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) Read of size 40 at addr ffff888122bf96d8 by task ping6/1543 CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:409 mm/kasan/report.c:521) kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1)) __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2)) rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282) lwtunnel_input (net/core/lwtunnel.c:459) ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1)) __netif_receive_skb_one_core (net/core/dev.c:5967) process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440) __napi_poll.constprop.0 (net/core/dev.c:7452) net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480 (discriminator 20)) __local_bh_enable_ip (kernel/softirq.c:407) __dev_queue_xmit (net/core/dev.c:4740) ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141) ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226) ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248) ip6_send_skb (net/ipv6/ip6_output.c:1983) rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918) __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1)) __x64_sys_sendto (net/socket.c:2231) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f68cffb2a06 Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06 RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003 RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4 R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0 Allocated by task 1543: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1)) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249) kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88)) __alloc_skb (net/core/skbuff.c:669) __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1)) ip6_ ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: net: sierra: comprobar si el endpoint no tiene estado. El controlador comprueba si hay tres endpoints y si hay endpoints de entrada y salida masivos, pero no si el tercer endpoint es una entrada de interrupción. Corrija la omisión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: Se corrige el error null-ptr-deref en l2cap_sock_resume_cb(). syzbot reportó un error null-ptr-deref en l2cap_sock_resume_cb(). [0] l2cap_sock_resume_cb() presenta un problema similar, corregido con el commit 1bff51ea59a9 ("Bluetooth: Se corrige el error de use-after-free en lock_sock_nested()"). Dado que tanto l2cap_sock_kill() como l2cap_sock_resume_cb() se ejecutan bajo l2cap_sock_resume_cb(), podemos evitar el problema simplemente comprobando si chan->data es NULL. No se accederá al socket eliminado en l2cap_sock_resume_cb(). [0]: BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline] BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Workqueue: hci0 hci_rx_work Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_report+0x58/0x84 mm/kasan/report.c:524 kasan_report+0xb0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37 instrument_atomic_write include/linux/instrumented.h:82 [inline] clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357 hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline] hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514 hci_event_func net/bluetooth/hci_event.c:7511 [inline] hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565 hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070 process_one_work+0x7e8/0x155c kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3321 [inline] worker_thread+0x958/0xed8 kernel/workqueue.c:3402 kthread+0x5fc/0x75c kernel/kthread.c:464 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_conntrack: corrección de fallo debido a la eliminación de una entrada no inicializada Se informó de un fallo en conntrack al intentar desvincular la entrada de conntrack de la lista de cubos hash: [exception RIP: __nf_ct_delete_from_lists+172] [..] #7 [ff539b5a2b043aa0] nf_ct_delete en ffffffffc124d421 [nf_conntrack] #8 [ff539b5a2b043ad0] nf_ct_gc_expired en ffffffffc124d999 [nf_conntrack] #9 [ff539b5a2b043ae0] __nf_conntrack_find_get en ffffffffc124efbc [nf_conntrack] [..] La estructura nf_conn está marcada como asignada desde slab, pero parece estar parcialmente inicializada: el puntero hlist ct es basura; parece el valor hash ct (de ahí el fallo). ct->status es igual a IPS_CONFIRMED|IPS_DYING, que es lo esperado ct->timeout es 30000 (=30 s), lo cual es inesperado. Todo lo demás parece una entrada conntrack udp normal. Si ignoramos ct->status y suponemos que es 0, la entrada coincide con las que se acaban de asignar pero que aún no se han insertado en el hash: - los punteros hlist ct están sobrecargados y almacenan/cachean el hash de la tupla sin procesar - ct->timeout coincide con el tiempo relativo esperado para un nuevo flujo udp en lugar del valor absoluto de 'jiffies'. Si no fuera por la presencia de IPS_CONFIRMED, __nf_conntrack_find_get() habría omitido la entrada. La teoría es que alcanzamos la siguiente ejecución: cpu x cpu y cpu z encontró la entrada E encontró la entrada EE está vencida nf_ct_delete() devuelve E a rcu slab init_conntrack E se reinicia, ct->status establecido en 0 respuesta tuplehash hnnode.pprev almacena el valor hash. cpu y encontró E justo antes de que se eliminara en la cpu x. E ahora se reinicia en la cpu z. La cpu y fue interrumpida antes de verificar la expiración y/o el bit de confirmación. ->refcnt establecido en 1 E ahora es propiedad de skb ->timeout establecido en 30000 Si la cpu y se reanudara ahora, observaría que E ha expirado, pero omitiría E debido a que falta el bit CONFIRMED. nf_conntrack_confirm se llama establece: ct->status |= CONFIRMED Esto es incorrecto: E aún no se agregó a la tabla hash. La CPU y se reanuda, observa que E ha expirado pero CONFIRMADO: nf_ct_expired() -> sí (ct->el tiempo de espera es de 30 s) bit confirmado establecido. La CPU y intentará eliminar E de la tabla hash: nf_ct_delete() -> establecer bit MORIR __nf_ct_delete_from_lists Incluso este escenario no garantiza un fallo: la CPU z aún mantiene el/los bloqueo(s) del depósito de la tabla, por lo que y bloquea: esperar a que z mantenga el bloqueo de giro CONFIRMADO está establecido, pero no hay garantía de que ct se agregue al hash: la lógica "chaintoolong" o "clash resolution" omiten el paso de inserción. responder hnnode.pprev aún almacena el valor del hash. desbloquea el bloqueo de giro devolver NF_DROP En caso de que la CPU z inserte la entrada en la tabla hash, la CPU y desvinculará E nuevamente de inmediato, pero no ocurre ningún fallo. Sin la ejecución de la CPU y, la lista de memoria basura no tiene importancia: ct refcnt permanece en 1, skb se liberará y E se destruirá mediante nf_conntrack_put -> nf_conntrack_destroy -> nf_ct_destroy. Para resolver esto, mueva la asignación IPS_CONFIRMED después de la inserción de la tabla, pero antes del desbloqueo. Pablo señala que el almacenamiento de bits de confirmación podría reordenarse para que ocurra antes de la adición de la lista de memoria o de la corrección del tiempo de espera, por lo que se debe cambiar a set_bit y a la barrera de memoria before_atomic para evitarlo. No importa si otras CPU pueden observar una entrada recién insertada justo antes de que se establezca el bit CONFIRMED: este evento no se distingue del caso anterior, "E es la encarnación anterior": la entrada se omitirá. También modifique nf_ct_should_gc() para que primero verifique el bit confirmado. La secuencia de gc es: 1. Verificar si la entrada ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: comedi: Se corrige la inicialización de datos para instrucciones que escriben en el subdispositivo Se sabe que algunos controladores de instrucciones del subdispositivo Comedi acceden a elementos de datos de instrucción más allá de los primeros elementos `insn->n` en algunos casos. Las funciones `do_insn_ioctl()` y `do_insnlist_ioctl()` asignan al menos `MIN_SAMPLES` (16) elementos de datos para lidiar con esto, pero no inicializan todo eso. Para los códigos de instrucción Comedi que escriben en el subdispositivo, los primeros elementos de datos `insn->n` se copian del espacio de usuario, pero los elementos restantes se dejan sin inicializar. Eso podría ser un problema si el controlador de instrucciones del subdispositivo lee los datos no inicializados. Asegúrese de que los primeros elementos `MIN_SAMPLES` se inicialicen antes de llamar a estos controladores de instrucciones, llenando los elementos no copiados con 0. Para `do_insnlist_ioctl()`, se utilizan los mismos elementos del búfer de datos para manejar una lista de instrucciones, así que asegúrese de que los primeros elementos `MIN_SAMPLES` se inicialicen para cada instrucción que escriba en el subdispositivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: sch_qfq: Corrección de la condición de ejecución en qfq_aggregate. Una condición de ejecución puede ocurrir cuando se modifica 'agg' en qfq_change_agg (llamado durante qfq_enqueue) mientras otros subprocesos acceden a él simultáneamente. Por ejemplo, qfq_dump_class puede desencadenar una desreferencia a NULL y qfq_delete_class puede causar un use-after-free. Este parche soluciona el problema mediante: 1. El traslado de qfq_destroy_class a la sección crítica. 2. La adición de la protección sch_tree_lock a qfq_dump_class y qfq_dump_class_stats.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: comedi: Se corrige el uso de datos no inicializados en insn_rw_emulate_bits(). Para las instrucciones `INSN_READ` e `INSN_WRITE` de Comedi en subdispositivos "digitales" (tipos de subdispositivo `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO` y `COMEDI_SUBD_DIO`), es común que el controlador del subdispositivo no tenga las funciones de controlador `insn_read` e `insn_write`, sino una función de controlador `insn_bits` para manejar las instrucciones `INSN_BITS` de Comedi. En ese caso, los punteros del controlador de función `insn_read` y/o `insn_write` del subdispositivo se configuran para apuntar a la función `insn_rw_emulate_bits()` mediante `__comedi_device_postconfig()`. Para `INSN_WRITE`, `insn_rw_emulate_bits()` actualmente asume que el valor `data[0]` proporcionado es una copia válida de la memoria del usuario. Al menos existirá porque `do_insnlist_ioctl()` y `do_insn_ioctl()` en "comedi_fops.c" garantizan la asignación de al menos `MIN_SAMPLES` (16) elementos. Sin embargo, si `insn->n` es 0 (lo cual es permitido para las instrucciones `INSN_READ` e `INSN_WRITE`, entonces `data[0]` puede contener datos no inicializados, y ciertamente contiene datos no válidos, posiblemente de una instrucción diferente en la matriz de instrucciones manejadas por `do_insnlist_ioctl()`. Esto dará como resultado que se escriba un valor incorrecto en el canal de salida digital (o en el canal de entrada/salida digital si se configura como una salida), y puede reflejarse en el estado guardado interno del canal. Arréglelo devolviendo 0 temprano si `insn->n` es 0, antes de llegar al código que accede a `data[0]`. Anteriormente, la función siempre devolvía 1 en caso de éxito, pero se supone que es el número de muestras de datos realmente leídas o escritas hasta `insn->n`, que es 0 en este caso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: comedi: Error en el ioctl COMEDI_INSNLIST si n_insns es demasiado grande El manejo del ioctl `COMEDI_INSNLIST` asigna un búfer del kernel para contener la matriz de `struct comedi_insn`, obteniendo la longitud del miembro `n_insns` de la `struct comedi_insnlist` proporcionada por el usuario. La asignación fallará con un WARNING y un volcado de pila si es demasiado grande. Evítelo fallando con un error `-EINVAL` si el valor `n_insns` proporcionado no es razonable. Defina el límite en el valor `n_insns` en la macro `MAX_INSNS`. Establezca esto en el mismo valor que `MAX_SAMPLES` (65536), que es la suma máxima permitida de los valores del miembro `n` en la matriz de `struct comedi_insn`, y las instrucciones comedi sensatas tendrán un `n` de al menos 1.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smc: Se corrigen varios errores debido a la confusión de tipos inet_sock. syzbot reportó símbolos extraños [0][1] en cipso_v4_sock_setattr() al liberar inet_sk(sk)->inet_opt. La dirección se liberó varias veces a pesar de ser memoria de solo lectura. cipso_v4_sock_setattr() no causó ningún error, y la causa raíz fue la confusión de tipos. La confirmación citada permitió crear smc_sock como un socket INET. El problema es que struct smc_sock no tiene struct inet_sock como primer miembro, sino que secuestra AF_INET y AF_INET6 sk_family, lo que confunde varias ubicaciones. En este caso, inet_sock.inet_opt era en realidad smc_sock.clcsk_data_ready(), que es una dirección de una función en el segmento de texto. $ pahole -C inet_sock vmlinux struct inet_sock { ... struct ip_options_rcu * inet_opt; /* 784 8 */ $ pahole -C smc_sock vmlinux struct smc_sock { ... void (*clcsk_data_ready)(struct sock *); /* 784 8 */ The same issue for another field was reported before. [2][3] At that time, an ugly hack was suggested [4], but it makes both INET and SMC code error-prone and hard to change. Also, yet another variant was fixed by a hacky commit 98d4435efcbf3 ("net/smc: prevent NULL pointer dereference in txopt_get"). Instead of papering over the root cause by such hacks, we should not allow non-INET socket to reuse the INET infra. Let's add inet_sock as the first member of smc_sock. [0]: kvfree_call_rcu(): Double-freed call. rcu_head 000000006921da73 WARNING: CPU: 0 PID: 6718 at mm/slab_common.c:1956 kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 Modules linked in: CPU: 0 UID: 0 PID: 6718 Comm: syz.0.17 Tainted: G W 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 lr : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 sp : ffff8000a03a7730 x29: ffff8000a03a7730 x28: 00000000fffffff5 x27: 1fffe000184823d3 x26: dfff800000000000 x25: ffff0000c2411e9e x24: ffff0000dd88da00 x23: ffff8000891ac9a0 x22: 00000000ffffffea x21: ffff8000891ac9a0 x20: ffff8000891ac9a0 x19: ffff80008afc2480 x18: 00000000ffffffff x17: 0000000000000000 x16: ffff80008ae642c8 x15: ffff700011ede14c x14: 1ffff00011ede14c x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011ede14c x10: 0000000000ff0100 x9 : 5fa3c1ffaf0ff000 x8 : 5fa3c1ffaf0ff000 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a03a7078 x4 : ffff80008f766c20 x3 : ffff80008054d360 x2 : 0000000000000000 x1 : 0000000000000201 x0 : 0000000000000000 Call trace: kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 (P) cipso_v4_sock_setattr+0x2f0/0x3f4 net/ipv4/cipso_ipv4.c:1914 netlbl_sock_setattr+0x240/0x334 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa8/0x158 security/smack/smack_lsm.c:2581 smack_inode_setsecurity+0x378/0x430 security/smack/smack_lsm.c:2912 security_inode_setsecurity+0x118/0x3c0 security/security.c:2706 __vfs_setxattr_noperm+0x174/0x5c4 fs/xattr.c:251 __vfs_setxattr_locked+0x1ec/0x218 fs/xattr.c:295 vfs_setxattr+0x158/0x2ac fs/xattr.c:321 do_setxattr fs/xattr.c:636 [inline] file_setxattr+0x1b8/0x294 fs/xattr.c:646 path_setxattrat+0x2ac/0x320 fs/xattr.c:711 __do_sys_fsetxattr fs/xattr.c:761 [inline] __se_sys_fsetxattr fs/xattr.c:758 [inline] __arm64_sys_fsetxattr+0xc0/0xdc fs/xattr.c:758 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879 el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 [ ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net:vlan: fix VLAN 0 refcount desequilibrio de alternancia de filtrado durante el tiempo de ejecución. Suponiendo que la función "rx-vlan-filter" esté habilitada en un dispositivo de red, el módulo 8021q agregará o eliminará automáticamente la VLAN 0 cuando el dispositivo de red se active o desactive administrativamente, respectivamente. Existen un par de problemas con el esquema anterior. El primer problema es una fuga de memoria que puede ocurrir si la función "rx-vlan-filter" está deshabilitada mientras el dispositivo está en ejecución: # ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1 Cuando el dispositivo se desactiva administrativamente, la función "rx-vlan-filter" está deshabilitada, por lo que el módulo 8021q no eliminará la VLAN 0 y se producirá una fuga de memoria [1]. Otro problema que puede ocurrir es que el kernel puede eliminar automáticamente la VLAN 0 cuando el dispositivo se pone administrativamente fuera de servicio a pesar de no haberla agregado cuando el dispositivo se puso administrativamente en servicio ya que durante ese tiempo la función "rx-vlan-filter" estaba deshabilitada. null-ptr-unref o bug_on[2] se activarán mediante unregister_vlan_dev() para el desequilibrio de refcount si se alterna el filtrado durante el tiempo de ejecución: $ ip link add bond0 type bond mode 0 $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q $ ethtool -K bond0 rx-vlan-filter off $ ifconfig bond0 up $ ethtool -K bond0 rx-vlan-filter on $ ifconfig bond0 down $ ip link del vlan0 La causa raíz es la siguiente: paso 1: agregue vlan0 para real_dev, como bond, team. register_vlan_dev vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1 paso2: deshabilitar la función de filtro de vlan y habilitar real_dev paso3: cambiar el filtro de 0 a 1 vlan_device_event vlan_filter_push_vids ndo_vlan_rx_add_vid //No se agregó refcnt a real_dev vlan0 paso4: real_dev inactivo vlan_device_event vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0 vlan_info_rcu_free //liberar vlan0 paso5: eliminar vlan0 unregister_vlan_dev BUG_ON(!vlan_info); //vlan_info es nulo Corrija ambos problemas anotando en la información de VLAN si la VLAN 0 se agregó automáticamente en NETDEV_UP y en función de eso decida si debe eliminarse en NETDEV_DOWN, independientemente del estado de la función "rx-vlan-filter". [1] objeto sin referencia 0xffff8880068e3100 (tamaño 256): comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): __kmalloc_cache_noprof+0x2b5/0x340 vlan_vid_add+0x434/0x940 vlan_device_event.cold+0x75/0xa8 notifier_call_chain+0xca/0x150 __dev_notify_flags+0xe3/0x250 rtnl_configure_link+0x193/0x260 rtnl_newlink_create+0x383/0x8e0 __rtnl_newlink+0x22c/0xa40 rtnl_newlink+0x627/0xb00 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 [2] kernel BUG at net/8021q/vlan.c:99! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1)) RSP: 0018:ffff88810badf310 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80 R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000 R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: TLS: siempre actualiza la cola al leer un archivo SOCK. Tras cambios recientes en Net-Next, TCP compacta los archivos SKB de forma mucho más agresiva. Esto reveló un error en TLS que permite intentar operar en un archivo SKB antiguo al comprobar si todos los archivos SKB de la cola tienen el mismo estado de descifrado y geometría. BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls] (net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544) Read of size 4 at addr ffff888013085750 by task tls/13529 CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme Call Trace: kasan_report+0xca/0x100 tls_strp_check_rcv+0x898/0x9a0 [tls] tls_rx_rec_wait+0x2c9/0x8d0 [tls] tls_sw_recvmsg+0x40f/0x1aa0 [tls] inet_recvmsg+0x1c3/0x1f0 Siempre recargue la cola, la ruta rápida es tener el registro en la cola cuando nos despertamos, de todos modos (es decir, la ruta que baja "if !strp->stm.full_len").