Vulnerabilidades

Vulnerabilidad de autorización faltante en los perfiles de usuario de ProfileGrid ProfileGrid. Este problema afecta a ProfileGrid: desde n/a hasta 5.9.3.

La vulnerabilidad de autorización faltante en Rextheme WP VR permite explotar niveles de seguridad de control de acceso configurados incorrectamente. Este problema afecta a WP VR: desde n/a hasta 8.5.4.

La vulnerabilidad de autorización faltante en Simple Custom Post Order de Colorlib permite explotar niveles de seguridad de control de acceso configurados incorrectamente. Este problema afecta a Simple Custom Post Order: desde n/a hasta 2.5.7.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netkit: Asignar bpf_net_context faltante Durante la introducción del manejo de struct bpf_net_context para la redirección XDP, se ha omitido el controlador netkit, que también lo requiere porque NETKIT_REDIRECT invoca skb_do_redirect() que accede a las variables por CPU. De lo contrario, vemos el siguiente fallo: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000038 bpf_redirect() netkit_xmit() dev_hard_start_xmit() Establezca bpf_net_context antes de invocar el programa netkit_xmit() dentro del controlador netkit.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: No devuelva skb OOB en manage_oob(). syzbot informó de un error de use after free en unix_stream_recv_urg(). [0] El escenario es 1. send(MSG_OOB) 2. recv(MSG_OOB) -> El OOB consumido permanece en la cola de recepción 3. send(MSG_OOB) 4. recv() -> manage_oob() devuelve el siguiente skb del OOB consumido -> Este también es OOB, pero unix_sk(sk)->oob_skb no se borra 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb se usa pero ya se liberó La reciente confirmación 8594d9b85c07 ("af_unix: No llame a skb_get() para skb OOB") descubrió el problema. Si se consume el skb OOB y se examina el siguiente skb en manage_oob(), aún necesitamos verificar si el skb es OOB. Hagámoslo recurriendo a las siguientes verificaciones en manage_oob() y agregando el caso de prueba en selftest. Tenga en cuenta que necesitamos agregar una verificación similar para SIOCATMARK. [0]: ERROR: KASAN: slab-use-after-free en unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Lectura de tamaño 4 en la dirección ffff8880326abcc4 por la tarea syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 No contaminado 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:93 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 descripción de la dirección de impresión mm/kasan/report.c:377 [en línea] informe de impresión+0x169/0x550 mm/kasan/report.c:488 informe de kasan+0x143/0x180 mm/kasan/report.c:601 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec red/socket.c:1046 [en línea] sock_recvmsg+0x22f/0x280 red/socket.c:1068 ____sys_recvmsg+0x1db/0x470 red/socket.c:2816 ___sys_recvmsg red/socket.c:2858 [en línea] __sys_recvmsg+0x2f0/0x3e0 red/socket.c:2888 do_syscall_x64 arch/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 DESCARGA: 0033:0x7f5360d6b4e9 Código: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 000000000 0000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Asignado por la tarea 5235: kasan_save_stack mm/kasan/common.c:47 [en línea] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [en línea] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [en línea] slab_post_alloc_hook mm/slub.c:3988 [en línea] slab_alloc_node mm/slub.c:4037 [en línea] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [en línea] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [en línea] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [en línea] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 do_syscall_x64 arch/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 Liberado por la tarea ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7996: usar hweight16 para obtener la antena tx correcta La máscara de cadena es u16, por lo que usar hweight8 no puede obtener la tx_ant correcta. Sin este parche, la tx_ant de la banda 2 sería -1 y provocaría el siguiente problema: ERROR: KASAN: pila fuera de los límites en mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7915: se corrige el error en mt7986 que no es dbdc mt7915_band_config() establece band_idx = 1 en el phy principal para mt7986 con MT7975_ONE_ADIE o MT7976_ONE_ADIE. el commit 0335c034e726 ("wifi: mt76: se corrige la condición de ejecución relacionada con la comprobación del estado de llenado de la cola de transmisión") introdujo una desreferencia de la matriz phys indexada indirectamente por band_idx a través de wcid->phy_idx en mt76_wcid_cleanup(). Esto provocó los siguientes errores en los dispositivos mt7986 afectados: No se puede manejar la lectura del kernel desde la memoria ilegible en la dirección virtual 0000000000000024 Información de aborto de memoria: ESR = 0x0000000096000005 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: error de traducción de nivel 1 Información de aborto de datos: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 pgtable de usuario: 4k páginas, VA de 39 bits, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Error interno: Oops: 0000000096000005 [#1] Módulos SMP vinculados en: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd No contaminado 5.15.150 #0 Nombre del hardware: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 00000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 000000000000000 x11: 000000000000000 x10: ffffff8004172e30 x9: ffffff8004172e28 x8: 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 00000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Rastreo de llamadas: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Código: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ fin del seguimiento 7e42dd9a39ed2281 ]--- Se soluciona mediante mt76_dev_phy() que asignará band_idx al phy correcto para todas las combinaciones de hardware.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: 9410/1: vfp: usar asm volátil en macros fmrx/fmxr Las instrucciones de punto flotante en el espacio de usuario pueden bloquear algunos kernels de ARM creados con clang/LLD 17.0.6: ERROR: instrucción FP no compatible en modo kernel FPEXC == 0xc0000780 Error interno: Ups - instrucción no definida: 0 [#1] CPU ARM: 0 PID: 196 Comm: vfp-reproducer No contaminado 6.10.0 #1 Nombre del hardware: BCM2835 La PC está en vfp_support_entry+0xc8/0x2cc LR está en do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Indicadores: NzCv IRQ en FIQ en modo SVC_32 ISA ARM Segmento ninguno Control: 00c5387d Tabla: 0251c008 DAC: 00000051 Información del registro r0: Información del registro r1: memoria vmalloc Información del registro r2: memoria no slab/vmalloc Información del registro r3: memoria no slab/vmalloc Información del registro r4: región vmalloc de 2 páginas Información del registro r5: slab kmalloc-cg-2k Información del registro r6: memoria vmalloc Información del registro r7: memoria no slab/vmalloc Información del registro r8: memoria no paginada Información del registro r9: puntero de tamaño cero Información del registro r10: memoria vmalloc Información del registro r11: memoria no paginada Información del registro r12: memoria no paginada Proceso vfp-reproducer (pid: 196, límite de pila = 0x61aaaf8b) Pila: (0xdc8d1f68 a 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 7d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Seguimiento de llamadas: [] (vfp_support_entry) desde [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) desde [] (__und_usr+0x70/0x80) Pila de excepciones (0xdc8d1fb0 a 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Código: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ fin del seguimiento 000000000000000 ]--- Pánico del kernel: no sincroniza: Excepción fatal en la interrupción ---[ fin del kernel: no sincroniza: Excepción fatal en la interrupción ]--- Este es un reproductor de espacio de usuario mínimo en una Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf("%fn", NAN + *(volatile double *)&v); return 0; } Otra forma de activar consistentemente el error es: calvin@raspberry-pi-zero-w ~$ python -c "import json" El error se reproduce solo cuando el kernel se construye con DYNAMIC_DEBUG=n, porque las llamadas pr_debug() actúan como barreras incluso cuando no están activadas. Esta es la salida de la misma fuente del kernel creada con el mismo compilador y DYNAMIC_DEBUG=y, donde el reproductor de espacio de usuario funciona como se espera: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Buscar burdamente instrucciones vmsr/vmrs en el texto casi idéntico de vfp_support_entry() hace que el problema sea obvio: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: fix potential no valid pointer dereference in blk_add_partition La función blk_add_partition() inicialmente usaba una sola condición if (IS_ERR(part)) para verificar errores al agregar una partición. Esto se modificó para manejar el caso específico de -ENXIO por separado, lo que permite que la función continúe sin registrar el error en este caso. Sin embargo, este cambio dejó involuntariamente una ruta donde se podía llamar a md_autodetect_dev() sin confirmar que part es un puntero válido. Esta confirmación separa la lógica de manejo de errores al dividir la condición if inicial, lo que mejora la legibilidad del código y maneja escenarios de error específicos de manera explícita. La función ahora distingue el caso de error general de -ENXIO sin alterar el comportamiento existente de las llamadas a md_autodetect_dev().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque, bfq: corregir posible UAF para bfqq->bic con cadena de fusión 1) estado inicial, tres tareas: Proceso 1 Proceso 2 Proceso 3 (BIC1) (BIC2) (BIC3) | ? | ? | ? | | | | | | V | V | V | bfqq1 bfqq2 bfqq3 proceso ref: 1 1 1 2) bfqq1 fusionado con bfqq2: Proceso 1 Proceso 2 Proceso 3 (BIC1) (BIC2) (BIC3) | | | ? \--------------\| | | VV | bfqq1--------->bfqq2 bfqq3 proceso ref: 0 2 1 3) bfqq2 fusionado con bfqq3: Proceso 1 Proceso 2 Proceso 3 (BIC1) (BIC2) (BIC3) aquí -> ? | | \--------------\ \-------------\| VV bfqq1-------->bfqq2---------->bfqq3 ref. de proceso: 0 1 3 En este caso, la IO del Proceso 1 obtendrá primero bfqq2 de BIC1, y luego obtendrá bfqq3 a través de la cadena de fusión, y finalmente manejará la IO por bfqq3. Sin embargo, el código actual pensará que bfqq2 es propiedad de BIC1, como estado inicial, y establecerá bfqq2->bic en BIC1. bfq_insert_request -> por Proceso 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> obtener bfqq2 de BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq si (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> grabar BIC1 en bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> obtener bfqq3 de bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> manejar IO por bfqq3 Solucione el problema verificando que bfqq sea primero de la cadena de fusión. Y esto podría solucionar el siguiente problema informado por nuestro syzkaller (irreproducible): ===================================================================== ERROR: KASAN: slab-use-after-free en el bloque bfq_do_early_stable_merge/bfq-iosched.c:5692 [en línea] ERROR: KASAN: slab-use-after-free en el bloque bfq_do_or_sched_stable_merge/bfq-iosched.c:5805 [en línea] ERROR: KASAN: slab-use-after-free en el bloque bfq_get_queue+0x25b0/0x2610/bfq-iosched.c:5889 Escribir de tamaño 1 en la dirección ffff888123839eb8 por la tarea kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Contaminado: GL 6.6.0-07439-gba2303cacfda #6 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Cola de trabajo: kblockd blk_mq_requeue_work Rastreo de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [en línea] imprimir_informe+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bloque bfq_do_early_stable_merge/bfq-iosched.c:5692 [en línea] bloque bfq_do_or_sched_stable_merge/bfq-iosched.c:5805 [en línea] bloque bfq_get_queue+0x25b0/0x2610/bfq-iosched.c:5889 bloque bfq_get_bfqq_handle_split+0x169/0x5d0/bfq-iosched.c:6757 bloque bfq_init_rq/bfq-iosched.c:6876 [en línea] bloque bfq_insert_request/bfq-iosched.c:6254 [en línea] bloque bfq_insert_requests+0x1112/0x5cf0/bfq-iosched.c:6304 bloque blk_mq_insert_request+0x290/0x8d0/blk-mq.c:2593 bloque blk_mq_requeue_work+0x6bc/0xa70/blk-mq.c:1502 proceso_uno_trabajo kernel/workqueue.c:2627 [en línea] proceso_trabajos_programados+0x432/0x13f0 kernel/workqueue.c:2700 subproceso_trabajador+0x6f2/0x1160 kernel/workqueue.c:2781 subproceso_k+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Asignado por la tarea 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [en línea] slab_post_alloc_hook mm/slab.h:763 [en línea] slab_alloc_node mm/slub.c:3458 [en línea] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [en línea] ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: evitar posible desreferencia NULL en rt6_uncached_list_flush_dev() el commit culpable eliminó accidentalmente una comprobación para que rt->rt6i_idev fuera NULL, como lo detectó syzbot: Oops: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor No contaminado 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [en línea] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Código: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notificador_cadena_llamada+0x19f/0x3e0 kernel/notifier.c:93 llamar_notificadores_dispositivo_red_extack net/core/dev.c:2032 [en línea] llamar_notificadores_dispositivo_red_net/core/dev.c:2046 [en línea] anular_registro_de_varios_dispositivos_red_notificar+0xd81/0x1c40 net/core/dev.c:11352 anular_registro_de_varios_dispositivos_red_net/core/dev.c:11414 [en línea] anular_registro_de_cola_de_dispositivos_red_+0x303/0x370 net/core/dev.c:11289 anular_registro_de_dispositivo_red include/linux/netdevice.h:3129 [en línea] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [en línea] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [en línea] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [en línea] __se_sys_exit_group kernel/exit.c:1040 [en línea] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/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 DESCARGA: 0033:0x7f1acc77def9 Código: No se puede acceder a los bytes del código de operación en 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 00000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Módulos vinculados en: ---[ fin del seguimiento 000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [en línea] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Código: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: bcm: Borrar bo->bcm_proc_read después de remove_proc_entry(). syzbot informó una advertencia en bcm_release(). [0] El cambio en cuestión corrigió otra advertencia que se activa cuando se vuelve a emitir connect() para un socket cuyo dispositivo conectado se ha anulado el registro. Sin embargo, si el socket simplemente se cierra sin el segundo connect(), el bo->bcm_proc_read restante activa un remove_proc_entry() innecesario en bcm_release(). Borremos bo->bcm_proc_read después de remove_proc_entry() en bcm_notify(). [0] nombre '4986' ADVERTENCIA: CPU: 0 PID: 5234 en fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Módulos vinculados en: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 No contaminado 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Código: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 0 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 00000000000000000 RSI: 0000000000000000 RDI: 00000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [en línea] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [en línea] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [en línea] __se_sys_exit_group kernel/exit.c:1040 [en línea] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/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:0x7fcfb51ee969 Código: No se puede acceder a los bytes del código de operación en 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160