Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrigió la desreferencia del puntero NULL en ocfs2_journal_dirty() bdev->bd_super se eliminó y commit 8887b94d9322 cambió el uso de bdev->bd_super a b_assoc_map->host->i_sb. Esto introduce la siguiente desreferencia del puntero NULL en ocfs2_journal_dirty() ya que b_assoc_map aún no está inicializado. Esto se puede reproducir fácilmente ejecutando xfstests generic/186, que no simula más créditos. [134.351592] ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000... [134.355341] RIP: 0010:ocfs2_journal_dirty+0x14f/0x160 [ocfs2]... [134.365071] Seguimiento de llamadas: [134.3653 12] [134.365524] ? __die_body+0x1e/0x60 [ 134.365868] ? page_fault_oops+0x13d/0x4f0 [134.366265]? __pfx_bit_wait_io+0x10/0x10 [134.366659]? horario+0x27/0xb0 [ 134.366981] ? exc_page_fault+0x6a/0x140 [134.367356]? asm_exc_page_fault+0x26/0x30 [134.367762]? ocfs2_journal_dirty+0x14f/0x160 [ocfs2] [ 134.368305] ? ocfs2_journal_dirty+0x13d/0x160 [ocfs2] [ 134.368837] ocfs2_create_new_meta_bhs.isra.51+0x139/0x2e0 [ocfs2] [ 134.369454] ocfs2_grow_tree+0x688/0x8a0 [ocfs2] 134.369927] ocfs2_split_and_insert.isra.67+0x35c/0x4a0 [ocfs2] [ 134.370521] ocfs2_split_extent+0x314/0x4d0 [ocfs2] [ 134.371019] ocfs2_change_extent_flag+0x174/0x410 [ocfs2] [ 134.371566] ocfs2_add_refcount_flag+0x3fa/0x630 ocfs2] [134.372117] ocfs2_reflink_remap_extent+0x21b/0x4c0 [ocfs2] [134.372994]? inode_update_timestamps+0x4a/0x120 [134.373692]? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2] [ 134.374545] ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2] [ 134.375393] ocfs2_reflink_remap_blocks+0xe4/0x4e0 [ocfs2] [ 134.376197] ocfs2_remap_file_range+0x1de/0x390 [ocfs2] [ 13 4.376971] ? permiso_archivo_seguridad+0x29/0x50 [ 134.377644] vfs_clone_file_range+0xfe/0x320 [ 134.378268] ioctl_file_clone+0x45/0xa0 [ 134.378853] do_vfs_ioctl+0x457/0x990 [ 134.379 422] __x64_sys_ioctl+0x6e/0xd0 [ 134.379987] do_syscall_64+0x5d/0x170 [ 134.380550] entrada_SYSCALL_64_after_hwframe+ 0x76/0x7e [ 134.381231] RIP: 0033:0x7fa4926397cb [ 134.381786] Código: 73 01 c3 48 8b 0d bd 56 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f f84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8d 56 38 00 f7 d8 64 89 01 48 [ 134.383930] RSP: 002b:00007ffc2b39f7b8 : 00000246 ORIG_RAX: 00000000000000010 [ 134.384854] RAX : ffffffffffffffda RBX: 0000000000000004 RCX: 00007fa4926397cb [ 134.385734] RDX: 00007ffc2b39f7f0 RSI: 000000004020940d RDI: 0000000000000003 [ 134.386606] RBP: 0000000000000000 R08: 00111a82a4f015bb R09: 00007fa494221000 [ 134.387476] R10: 0000000000000000 R11: 0000000000000 246 R12: 0000000000000000 [ 134.388342] R13: 0000000000f10000 R14: 0000558e844e2ac8 R15: 0000000000f10000 [ 134.389207] Solucionelo abortando solo la transacción y el diario en ocfs2_journal_dirty() ahora, y deje ocfs2_abort() más tarde cuando detecte un identificador abortado, por ejemplo, iniciar la siguiente transacción. En este caso, registre también los detalles del identificador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: arreglar slab-out-of-bounds en ext4_mb_find_good_group_avg_frag_lists() Podemos activar un slab-out-of-bounds con los siguientes comandos: mkfs.ext4 -F /dev/ $disk 10G montaje /dev/$disk /tmp/test echo 2147483647 > /sys/fs/ext4/$disk/mb_group_prealloc echo test > /tmp/test/file && sync ============ ==================================================== ==== ERROR: KASAN: losa fuera de los límites en ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] Lectura de tamaño 8 en la dirección ffff888121b9d0f0 por tarea kworker/u2:0/11 CPU: 0 PID: 11 Comm: kworker/ u2:0 Tainted: GL 6.7.0-next-20240118 #521 Seguimiento de llamadas: dump_stack_lvl+0x2c/0x50 kasan_report+0xb6/0xf0 ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4_mb_regular_allocator+0x19e9 /0x2370 [ext4] text4_mb_new_blocks+0x88a/0x1370 [ text4] text4_ext_map_blocks+0x14f7/0x2390 [ext4] text4_map_blocks+0x569/0xea0 [ext4] text4_do_writepages+0x10f6/0x1bc0 [ext4] [...] ==================== ================================================ El flujo de La activación del problema es la siguiente: // Establezca s_mb_group_prealloc en 2147483647 a través de sysfs ext4_mb_new_blocks ext4_mb_normalize_request ext4_mb_normalize_group_request ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc ext4_mb_regular_allocator ext4_mb_choose _next_group ext4_mb_choose_next_group_best_avail mb_avg_fragment_size_order orden = fls(len) - 2 = 29 ext4_mb_find_good_group_avg_frag_lists frag_list = &sbi- >s_mb_avg_fragment_size[order] if (list_empty(frag_list)) // ¡Activa SOOB! En un tamaño de bloque de 4k, la longitud de la lista s_mb_avg_fragment_size es 14, pero se establece un s_mb_group_prealloc de gran tamaño, lo que provoca que los límites de losa se activen al intentar acceder a un elemento en el índice 29. Agregue un nuevo attr_id attr_clusters_in_group con valores en el rango [0, sbi->s_clusters_per_group] y declare mb_group_prealloc como ese tipo para solucionar el problema. Además, evite devolver un pedido de mb_avg_fragment_size_order() mayor que MB_NUM_ORDERS(sb) y reduzca algunos bucles inútiles.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ima: Evite el bloqueo en la sección crítica del lado de lectura de RCU Ocurre un pánico en ima_match_policy: ERROR: no se puede manejar la desreferencia del puntero NULL del kernel en 00000000000000010 PGD 42f873067 P4D 0 Ups: 0000 [#1 ] SMP NOPTI CPU: 5 PID: 1286325 Comm: kubeletmonit.sh Kdump: cargado Contaminado: P Nombre del hardware: QEMU PC estándar (i440FX + PIIX, 1996), BIOS 0.0.0 06/02/2015 RIP: 0010:ima_match_policy+0x84 /0x450 Código: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39 7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d f2 b9 f4 00 0f 84 9c 01 00 <44> 85 73 10 74 ea 44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f RSP: 0018:ff71570009e07a80 EFLAGS: 00010207 RAX: 0000000000000000 RBX: 0000000000 RCX: 0000000000000200 RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000 RBP: 0000000000000000 R08 : 0000000000000000 R09: ffffffffabfce739 R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970 R13: 00000000ff3e2785 R14: 000000000c R15: 0000000000000001 FS: 00007f5195b51740(0000) GS:ff3e278b12d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: : 0000000080050033 CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ima_get_action+0x22/0x30 Process_measurement+0xb0/0x830 ? page_add_file_rmap+0x15/0x170? alloc_set_pte+0x269/0x4c0? prep_new_page+0x81/0x140? simple_xattr_get+0x75/0xa0? selinux_file_open+0x9d/0xf0 ima_file_check+0x64/0x90 path_openat+0x571/0x1720 do_filp_open+0x9b/0x110 ? page_counter_try_charge+0x57/0xc0? files_cgroup_alloc_fd+0x38/0x60? __alloc_fd+0xd4/0x250? do_sys_open+0x1bd/0x250 do_sys_open+0x1bd/0x250 do_syscall_64+0x5d/0x1d0 Entry_SYSCALL_64_after_hwframe+0x65/0xca Commit c7423dbdbc9e ("ima: Handle -ESTALE devuelto por ima_filter_rule_match()") introdujo la llamada a ima_lsm _copy_rule dentro de una sección crítica del lado de lectura de RCU que contiene kmalloc con GFP_KERNEL. Esto implica una posible suspensión y viola las limitaciones de las secciones críticas del lado de lectura de RCU en sistemas que no son PREEMPT. Dormir dentro de la sección crítica del lado de lectura de la RCU puede provocar que sincronizar_rcu() regrese antes de tiempo y rompa la protección de la RCU, lo que permite que se produzca una UAF. La causa raíz de este problema podría describirse de la siguiente manera: | Hilo A | Hilo B | | |ima_match_policy | | | rcu_read_lock | |ima_lsm_update_rule | | | sincronizar_rcu | | | | kmalloc(GFP_KERNEL)| | | dormir | ==> sincronizar_rcu regresa temprano | kfree(entrada) | | | | entrada = entrada->siguiente| ==> Sucede UAF y la entrada ahora se vuelve NULL (o podría ser cualquier cosa). | | entrada->acción | ==> Acceder a la entrada puede causar pánico. Para solucionar este problema, estamos convirtiendo todos los kmalloc que se llaman dentro de la sección crítica del lado de lectura de RCU para usar GFP_ATOMIC. [PM: comentario faltante corregido, líneas largas, caso !CONFIG_IMA_LSM_RULES]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/page_table_check: corrige el fallo en ZONE_DEVICE Es posible que no todas las páginas se apliquen a la verificación de pgtable. Un ejemplo son las páginas ZONE_DEVICE: asignan PFN directamente y no asignan page_ext en absoluto, incluso si hay una página de estructura alrededor. Se puede hacer referencia a devm_memremap_pages(). Cuando tanto ZONE_DEVICE como page-table-check están habilitados, intente asignar algunas memorias dax, uno puede desencadenar un error del kernel constantemente ahora cuando el kernel intenta inyectar algunos mapas pfn en el dispositivo dax: ERROR del kernel en mm/page_table_check.c: 55! Si bien es bastante legal usar set_pxx_at() para páginas ZONE_DEVICE para resolución de fallas de página, omita todas las comprobaciones si page_ext ni siquiera existe en pgtable checker, lo que se aplica a ZONE_DEVICE pero tal vez más.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: solucione una ejecución de datos en last_boosted_vcpu en kvm_vcpu_on_spin() Utilice {READ,WRITE}_ONCE() para acceder a kvm->last_boosted_vcpu para garantizar que las cargas y los almacenes sean atómicos. En el escenario extremadamente improbable de que el compilador rompa los almacenes, es teóricamente posible que KVM intente obtener una vCPU utilizando un índice fuera de los límites, por ejemplo, si la escritura se divide en varios almacenes de 8 bits y se combina con un 32 -carga de bits en una VM con 257 vCPU: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; Según lo detectado por KCSAN: ERROR: KCSAN: ejecución de datos en kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] escribe en 0xffffc90025a92344 de 4 bytes por tarea 4340 en la CPU 16: kvm_vcpu_on_spin (arch/x86/kvm/../../. ./virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm /vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c :890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64 .S:130) leído en 0xffffc90025a92344 de 4 bytes por la tarea 4342 en la CPU 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/ x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86 .c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) Entry_SYSCALL_64_after_hwframe (arch/ x86/entry/entry_64.S:130) valor cambiado: 0x00000012 -> 0x00000000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: no deja un puntero sk colgando cuando falla la creación del socket. Es posible activar un use-after-free: * adjuntando una sonda fentry a __sock_release() y el sonda que llama al asistente bpf_get_socket_cookie() * ejecuta traceroute -I 1.1.1.1 en una máquina virtual recién iniciada. Un kernel habilitado para KASAN registrará algo como lo siguiente (decodificado y eliminado): =============== ==================================================== = ERROR: KASAN: slab-use-after-free en __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include /linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) Lectura de tamaño 8 en la dirección ffff888007110dd8 mediante tarea traceroute/299 CPU: 2 PID: 299 Comm: traceroute Contaminado: GE 6.10.0- rc2+ #2 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:117 ( discriminador 1)) print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 neto /core/sock_diag.c:29) kasan_report (mm/kasan/report.c:603)? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 neto /core/sock_diag.c:29) kasan_check_range (mm/kasan/generic.c:183 mm/kasan/generic.c:189) __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include /linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) bpf_get_socket_ptr_cookie (./arch/x86/include/asm /preempt.h:94 ./include/linux/sock_diag.h:42 net/core/filter.c:5094 net/core/filter.c:5092) bpf_prog_875642cf11f1d139___sock_release+0x6e/0x8e bpf_trampoline_6442506592+0x47/0xaf __ calcetín_release (net/ socket.c:652) __sock_create (net/socket.c:1601) ... Asignado por la tarea 299 en la CPU 2 en 78.328492s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common. c:68) __kasan_slab_alloc (mm/kasan/common.c:312 mm/kasan/common.c:338) kmem_cache_alloc_noprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007) sk_prot_alloc (net/core/sock.c:2075) sk_alloc (net/core/sock.c:2134) inet_create (net/ipv4/af_inet.c:327 net/ipv4/af_inet.c:252) __sock_create (net/socket. c:1572) __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) __x64_sys_socket (net/socket.c:1718) do_syscall_64 (arch/x86/entry/common.c: 52 arch/x86/entry/common.c:83) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Liberado por la tarea 299 en la CPU 2 a las 78.328502s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:68) kasan_save_free_info (mm/kasan/generic.c:582) veneno_slab_object (mm/kasan/common.c:242) __kasan_slab_free (mm/kasan/common.c:256) kmem_cache_free ( mm/slub.c:4437 mm/slub.c:4511) __sk_destruct (net/core/sock.c:2117 net/core/sock.c:2208) inet_create (net/ipv4/af_inet.c:397 net/ipv4 /af_inet.c:252) __sock_create (net/socket.c:1572) __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) __x64_sys_socket (net/socket.c:1718 ) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Solucione este problema borrando la referencia del socket de estructura en sk_common_release () para cubrir todas las familias de protocolos, cree funciones, que pueden ya adjuntar la referencia al objeto sk con sock_init_data().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: corrija posible Use-After-Free en irq_process_work_list Use list_for_each_entry_safe() para permitir iterar a través de la lista y eliminar la entrada en el proceso de iteración. El descriptor se libera a través de idxd_desc_complete() y existe una pequeña posibilidad de que cause problemas para el iterador de la lista cuando otro subproceso reutiliza el descriptor sin que se elimine de la lista.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: seg6: corrige el paso de parámetros al llamar a NF_HOOK() en los comportamientos End.DX4 y End.DX6 input_action_end_dx4() y input_action_end_dx6() se llaman NF_HOOK() para el gancho PREROUTING, en el gancho PREROUTING , debemos pasar un indev válido y un outdev NULL a NF_HOOK(); de lo contrario, podemos desencadenar una desreferencia del puntero NULL, como se muestra a continuación: [74830.647293] ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000090 [74830.655633] #PF: acceso de lectura del supervisor en modo kernel [74830.657888] #PF: error_code(0x0000) - página no presente [74830.659500] PGD 0 P4D 0 [74830.660450] Ups: 0000 [#1] PREEMPT SMP PTI... [74830.664953] Nombre de hardware: Red Hat KVM , BIOS 0.5.1 01/01/2011 [74830.666569] RIP: 0010:rpfilter_mt+0x44/0x15e [ipt_rpfilter] ... [74830.689725] Seguimiento de llamadas: [74830.690402] [74830.690953] ? show_trace_log_lvl+0x1c4/0x2df [74830.692020] ? show_trace_log_lvl+0x1c4/0x2df [74830.693095] ? ipt_do_table+0x286/0x710 [ip_tables] [74830.694275] ? __die_body.cold+0x8/0xd [74830.695205] ? page_fault_oops+0xac/0x140 [74830.696244] ? exc_page_fault+0x62/0x150 [74830.697225] ? asm_exc_page_fault+0x22/0x30 [74830.698344] ? rpfilter_mt+0x44/0x15e [ipt_rpfilter] [74830.699540] ipt_do_table+0x286/0x710 [ip_tables] [74830.700758] ? ip6_route_input+0x19d/0x240 [74830.701752] nf_hook_slow+0x3f/0xb0 [74830.702678] input_action_end_dx4+0x19b/0x1e0 [74830.703735] ? input_action_end_t+0xe0/0xe0 [74830.704734] seg6_local_input_core+0x2d/0x60 [74830.705782] lwtunnel_input+0x5b/0xb0 [74830.706690] __netif_receive_skb_one_core+0x63/0xa0 830.707825] proceso_atrasado+0x99/0x140 [74830.709538] __napi_poll+0x2c/0x160 [74830.710673] net_rx_action+ 0x296/0x350 [74830.711860] __do_softirq+0xcb/0x2ac [74830.713049] do_softirq+0x63/0x90 input_action_end_dx4() pasando un indev NULL a NF_HOOK(), y finalmente activa una desreferencia NULL en rpfilter_mt()->rpfilter_is_lo opback(): bool estático rpfilter_is_loopback (const struct sk_buff *skb, const struct net_device *in) { // in es NULL return skb->pkt_type == PACKET_LOOPBACK || en->flags & IFF_LOOPBACK; }

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netns: haga que get_net_ns() maneje cero refcount net. Syzkaller recibió una advertencia: refcount_t: adición en 0; use-after-free. ADVERTENCIA: CPU: 3 PID: 7890 en lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0 Módulos vinculados en: CPU: 3 PID: 7890 Comm: tun No contaminado 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310 Hardware nombre: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 01/04/2014 RIP: 0010:refcount_warn_saturate+0xdf/0x1d0 Código: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 <0f> 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1 RSP: 0018: ffff8881067b7da0 EFLAGS: 00010286 RAX: 00000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72ac RDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001 RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139 R10: 00000000000000000 R11: 205d303938375420 R12: 8881086500c4 R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040 FS : 00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fd18 CR3: 00000001482f6000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ? show_regs+0xa3/0xc0? __advertir+0xa5/0x1c0 ? refcount_warn_saturate+0xdf/0x1d0? report_bug+0x1fc/0x2d0? refcount_warn_saturate+0xdf/0x1d0? handle_bug+0xa1/0x110? exc_invalid_op+0x3c/0xb0? asm_exc_invalid_op+0x1f/0x30? __warn_printk+0xcc/0x140 ? __warn_printk+0xd5/0x140 ? refcount_warn_saturate+0xdf/0x1d0 get_net_ns+0xa4/0xc0 ? __pfx_get_net_ns+0x10/0x10 open_ related_ns+0x5a/0x130 __tun_chr_ioctl+0x1616/0x2370 ? __sanitizer_cov_trace_switch+0x58/0xa0? __sanitizer_cov_trace_const_cmp2+0x1c/0x30 ? __pfx_tun_chr_ioctl+0x10/0x10 tun_chr_ioctl+0x2f/0x40 __x64_sys_ioctl+0x11b/0x160 x64_sys_call+0x1211/0x20d0 do_syscall_64+0x9e/0x1d0 Entry_SYSCALL_64_after_h wframe+0x77/0x7f RIP: 0033:0x7f5b28f165d7 Código: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff 73 01 c3 48 8b 0d 81 48 2d 0 8 RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7 RDX: 000000000 RSI: 00000000000054e3 RDI: 0000000000000003 RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0 R10: 690010 R11: 0000000000000246 R12: 0000000000400730 R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 00000000000000000 Pánico del kernel - no sincronizado: kernel: pánico_on_warn set ... Esto se activa como se muestra a continuación: ns0 ns1 tun_set_iff() //dev is tun0 tun->dev = dev //ip link set tun0 netns ns1 put_net() //ref es 0 __tun_chr_ioctl() //TUNGETDEVNETNS net = dev_net(tun->dev); open_ related_ns(&net->ns, get_net_ns); //ns1 get_net_ns() get_net() //adición en 0 Use may_get_net() en get_net_ns en caso de que la referencia de red sea cero para solucionar este problema

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm6: verifique el valor de retorno de ip6_dst_idev() en xfrm6_get_saddr() ip6_dst_idev() puede devolver NULL, xfrm6_get_saddr() debe actuar en consecuencia. syzbot informó: Ups: falla 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 [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 12 Comm: trabajador/ u8:1 No contaminado 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 Cola de trabajo: wg-kex-wg1 wg_packet_handshake_send_worker RIP: 0010:xfrm6_get_saddr +0x93/0x130 net/ipv6/xfrm6_policy.c:64 Código: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff f 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00 RSP: 0018:ffffc90000117378 EFLAGS: 00010246 RAX dff ffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7 RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98 RBP: ffff88807ad73248 R08: 0000000000000007 R09: ffffffffffff000 R10: ffff88807b079dc0 11: 0000000000000007 R12: ffffc90000117480 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0 000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS : 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: xfrm_get_saddr net/xfrm/xfrm_policy .c:2452 [en línea] xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [en línea] xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541 xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_ política.c:2835 xfrm_bundle_lookup net /xfrm/xfrm_policy.c:3070 [en línea] xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201 xfrm_lookup net/xfrm/xfrm_policy.c:3298 [en línea] xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm _política.c :3309 ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256 send6+0x611/0xd20 controladores/net/wireguard/socket.c:139 wg_socket_send_skb_to_peer+0xf9/0x220 controladores/net/wireguard/socket.c:178 enviar_buffer_to_peer+ 0x12b/0x190 controladores/net/wireguard/socket.c:200 wg_packet_send_handshake_initiation+0x227/0x360 controladores/net/wireguard/send.c:40 wg_packet_handshake_send_worker+0x1c/0x30 controladores/net/wireguard/send.c:51 Process_one_work+0x9fb/ 0x1b60 kernel/workqueue.c:3231 Process_scheduled_works kernel/workqueue.c:3312 [en línea] trabajador_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/ x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/region: solucione las fugas de memregion en devm_cxl_add_region() Mueva el modo de verificación a __create_region() antes de asignar la memregion para evitar las fugas de memregion.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/kexec: Corrección de error con el seguimiento de profundidad de llamadas. La llamada a cc_platform_has() desencadena una falla y un bloqueo del sistema si el seguimiento de profundidad de llamadas está activo porque el segmento GS ha sido restablecido por load_segments( ) y GS_BASE ahora es 0, pero el seguimiento de profundidad de llamadas utiliza variables por CPU para funcionar. Llame a cc_platform_has() anteriormente en la función cuando GS aún sea válido. [pb: Masaje. ]