Vulnerabilidades

Si a un atacado se le dio acceso a una instancia con la función de administrador o administrador, no existe una autenticación de backend que impida que el atacado cree un nuevo usuario con una función de "administrador" y luego pueda usar esta nueva cuenta para tener privilegios elevados en la instancia

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: solo llame a folio_start_fscache() una vez para cada folio. Si un sistema de archivos de red que utiliza netfs implementa una función abrazadera_longitud(), puede establecer longitudes de subsolicitud más pequeñas que el tamaño de una página. Cuando recorremos las publicaciones en netfs_rreq_unlock_folios() para configurar las publicaciones que se reescribirán, debemos asegurarnos de llamar solo a folio_start_fscache() una vez para cada publicación. De lo contrario, este caso de prueba simple: mount -o fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count= 1 1+0 registros en 1+0 registros en salida 4096 bytes (4,1 kB, 4,0 KiB) copiados, 0,0126359 s, 324 kB/s echo 3 > /proc/sys/vm/drop_caches cat /mnt/nfs/file.bin > /dev/null desencadenará un error similar al siguiente: página volcada porque: VM_BUG_ON_FOLIO(folio_test_private_2(folio)) ------------[ cortar aquí ]---------- -- ¡ERROR del kernel en include/linux/netfs.h:44! ... CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: cargado No contaminado 6.4.0-rc5 ... RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs] ... Seguimiento de llamadas: netfs_rreq_assess+0x497 /0x660 [netfs] netfs_subreq_terminate+0x32b/0x610 [netfs] nfs_netfs_read_completion+0x14e/0x1a0 [nfs] nfs_read_completion+0x2f9/0x330 [nfs] rpc_free_task+0x72/0xa0 [sunrpc] rpc_a sync_release+0x46/0x70 [sunrpc] proceso_one_work+0x3bd/0x710 hilo_trabajador+0x89/0x610 kthread+0x181/0x1c0 ret_from_fork+0x29/0x50

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/core: Reparar el disector de flujo ETH_P_1588 Cuando se envía una trama sin formato Ethernet PTP con un tamaño de más de 256 bytes seguido de un patrón 0xff a __skb_flow_dissect, el cálculo del valor nhoff es incorrecto. Por ejemplo: hdr->message_length toma el valor incorrecto (0xffff) y no replica la longitud real del encabezado. En este caso, se anuló el valor 'nhoff' y el encabezado PTP no se analizó correctamente. Esto provoca un fallo del kernel. neto/núcleo: flow_dissector disector de flujo neto/núcleo nhoff = 0x0000000e disector de flujo neto/núcleo hdr->message_length = 0x0000ffff disector de flujo neto/núcleo nhoff = 0x0001000d (desbordamiento u16) ... skb lineal: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 skb frag: 00000000: f7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff El uso del tamaño de la estructura ptp_header permitirá el cálculo corregido del valor nhoff. disector de flujo neto/núcleo nhoff = 0x0000000e disector de flujo neto/núcleo nhoff = 0x00000030 (tamaño de ptp_header) ... skb lineal: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 f7 ff ff skb lineal: 00000 010:ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff skb lineal: 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff skb frag: 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Seguimiento del kernel: [74.984279] ------------[ cortar aquí ]------------ [ 74.989471] ERROR del kernel en include/linux /skbuff.h:2440! [ 74.995237] código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI [ 75.001098] CPU: 4 PID: 0 Comm: swapper/4 Tainted: GU 5.15.85-intel-ese-standard-lts #1 [ 75.011629] Nombre de hardware: Intel Corporation A-Island (CPU:AlderLake)/A-Island (ID:06), BIOS SB_ADLP.01.01.00.01.03.008.D-6A9D9E73-dirty 30 de marzo de 2023 [ 75.026507] RIP: 0010:eth_type_trans+0xd0/0x130 [ 75.031594] Código: 03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb ab <0f> 0b b8 00 01 00 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9 [ 75.052612] RSP: 0018:ffff9948c0228de0 EFLAGS: 00010297 [ 75.058473] RAX: 0000000 0000003f2 RBX: ffff8e47047dc300 RCX: 0000000000001003 [ 75.066462] RDX: ffff8e4e8c9ea040 RSI : ffff8e4704e0a000 RDI: ffff8e47047dc300 [ 75.074458] RBP: ffff8e4704e2acc0 R08: 00000000000003f3 R09: 0000000000000800 [ 75.082466] R10: 00 0000000000000d R11: ffff9948c0228dec R12: ffff8e4715e4e010 [ 75.090461] R13: ffff9948c0545018 R14: 00000000000000001 R15: 00000000000000800 [ 75.098464] FS: 0000000000000000(0000) GS:ffff8e4e8fb00000(0000) knlGS:00000000000000000 [ 75.107530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 75.113982] CR2: 00007f5eb3593 4a0 CR3: 0000000150e0a002 CR4: 0000000000770ee0 [ 75.121980] PKRU: 55555554 [ 75.125035] Seguimiento de llamadas: [ 75.127792 ] [75.130063] ? eth_get_headlen+0xa4/0xc0 [ 75.134472] igc_process_skb_fields+0xcd/0x150 [ 75.139461] igc_poll+0xc80/0x17b0 [ 75.143272] __napi_poll+0x27/0x170 [ 75.147192] net_ rx_action+0x234/0x280 [ 75.151409] __do_softirq+0xef/0x2f4 [ 75.155424] irq_exit_rcu+ 0xc7/0x110 [ 75.159432] common_interrupt+0xb8/0xd0 [ 75.163748] [ 75.166112] [ 75.168473] asm_common_interrupt+0x22/0x40 [ 75.173175] RIP: 0010:cpuid le_enter_state+0xe2/0x350 [ 75.178749] Código: 85 c0 0f 8f 04 02 00 00 31 ff e8 39 6c 67 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 50 02 00 00 31 ff e8 52 b0 6d ff fb 45 85 f6 <0f> 88 b1 00 0 0 00 49 63 ce 4c 2b 2c 24 48 89 c8 48 6b d1 68 48 c1 [ 75.199757] RSP: 0018:ffff9948c013bea8 EFLAGS: 00000202 [ 75.205614] RAX: ffff8e4e8fb00000 RBX: ff ffb948bfd23900 RCX: 000000000000001f [ 75.213619] RDX: 0000000000000004 RSI: ffffffff94206161 RDI: ffffffff94212e20 [ 75.221620] RBP: 0000000000000004 R08: 000000117568973a R09: 0000000000000001 [ 75.229622] R10: 000000000000afc8 R11: ffff8e4e8fb29ce4 R12: ffffffff945ae980 [ 75.237628] R13: 000000117568973a R14: 0000000000000004 R15: 0000000000000000 [ 75.245635] ? ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: rds: corrige la posible desreferencia del puntero NULL. En rds_rdma_cm_event_handler_cmn(), verifique si el puntero de conexión existe antes de desreferenciarlo como argumento rdma_set_service_type() Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfio/mdev: corrige un error null-ptr-deref para mdev_unregister_parent() Inyecta el fallo al sondear mdpy.ko, si kstrdup() de create_dir() falla en kobject_add_internal() en kobject_init_and_add() en mdev_type_add() en parent_create_sysfs_files(), devolverá 0 y sondeará exitosamente. Y cuando rmmod mdpy.ko, mdpy_dev_exit() llamará a mdev_unregister_parent(), mdev_type_remove() puede atravesar tipos padre->[i] no inicializados en parent_remove_sysfs_files(), y provocará debajo de null-ptr-deref. Si mdev_type_add() falla, devuelva el código de error y kset_unregister() para solucionar el problema. falla de protección general, probablemente para dirección no canónica 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en rango [0x0000000000000010-0x00000000000000017] CPU: 2 PID: 10215 Comm: rmmod Tainted: GW N 6.6.0- rc2+ #20 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1 01/04/2014 RIP: 0010:__kobject_del+0x62/0x1c0 Código: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 51 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 28 48 8d 7d 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 24 01 00 00 48 8b 7 5 10 48 89 gl 48 8d 6b 3c e8 RSP: 0018:ffff88810695fd30 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffffa0270268 RCX: 00000000000000000 RDX: 0000000000000000 2 RSI: 0000000000000004 RDI: 00000000000000010 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed10233a4ef1 R10: ffff888119d2778b R11: 00 00000063666572 R12: 0000000000000000 R13 : ffffbfff404e2d4 R14: dffffc0000000000 R15: fffffffa0271660 FS: 00007fbc81981540(0000) GS:ffff888119d00000(0000) knlGS:0000000000000000 CS: 0010 DS : 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc14a142dc0 CR3: 0000000110a62003 CR4: 0000000000770ee0 DR0: ffffffff8fb0bce8 DR1: ffffffff8fb0bce9 DR2: ffffffff8fb0bcea DR3: ffffffff8fb0bceb DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Seguimiento de llamadas: ? die_addr+0x3d/0xa0? exc_general_protection+0x144/0x220? asm_exc_general_protection+0x22/0x30? __kobject_del+0x62/0x1c0 kobject_del+0x32/0x50 parent_remove_sysfs_files+0xd6/0x170 [mdev] mdev_unregister_parent+0xfb/0x190 [mdev] ? mdev_register_parent+0x270/0x270 [mdev] ? find_module_all+0x9d/0xe0 mdpy_dev_exit+0x17/0x63 [mdpy] __do_sys_delete_module.constprop.0+0x2fa/0x4b0 ? module_flags+0x300/0x300? __fput+0x4e7/0xa00 do_syscall_64+0x35/0x80 Entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fbc813221b7 Código: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe780e0648 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 RAX : ffffffffffffffda RBX: 00007ffe780e06a8 RCX: 00007fbc813221b7 RDX: 000000000000000a RSI: 00000000000000800 RDI: 000055e214df9b58 RBP: 000055e214d f9af0 R08: 00007ffe780df5c1 R09: 00000000000000000 R10: 00007fbc8139ecc0 R11: 0000000000000206 R12: 00007ffe780e0870 R13: 00007ffe780e0ed0 R14: 000055e214df9260 R15: 000055e214df9af0 Módulos vinculados en: mdpy(-) mdev vfio_iommu_type1 vfio [última descarga: mdpy] Dumping ftrace buffer: (ftrace buffer vacío) ---[ end trace 0000000000000000 ]--- RIP: 0010:__kobject_del+0x62/0x1c0 Código: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 51 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 28 48 8d 7d 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 24 01 00 00 48 8b 75 10 48 89 df 48 8d 6b 3c e8 RSP: 0018:ffff88810695fd30 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: fffffffa0270268 RCX: 00000000000000000 RDX: 0000000000000002 RSI: 0000000000000004 RDI: 0000000000000010 RBP: 0000000000000000 R08: 00000000000000001 R09: ffffed10233a4ef1 R10: ff ff888119d2778b R11: 0000000063666572 R12: 00000000000000000 R13: ffffbfff404e2d4 R14: dffffc0000000000 R15: ffffffffa0271660 FS: 00007fbc81981540(0000) GS:ffff88 8119d00000(000 ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: equipo: corrige null-ptr-deref cuando se cambia el tipo de dispositivo del equipo. Obtiene un error null-ptr-deref de la siguiente manera con el reproductor [1]. ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000228... RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]... Seguimiento de llamadas: ? __morir+0x24/0x70 ? page_fault_oops+0x82/0x150? exc_page_fault+0x69/0x150? asm_exc_page_fault+0x26/0x30? vlan_dev_hard_header+0x35/0x140 [8021q] ? vlan_dev_hard_header+0x8e/0x140 [8021q] neigh_connected_output+0xb2/0x100 ip6_finish_output2+0x1cb/0x520 ? nf_hook_slow+0x43/0xc0? ip6_mtu+0x46/0x80 ip6_finish_output+0x2a/0xb0 mld_sendpack+0x18f/0x250 mld_ifc_work+0x39/0x160 Process_one_work+0x1e6/0x3f0 trabajador_thread+0x4d/0x2f0? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 [1] $ teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}' $ enlace ip agregar nombre t-dummy tipo dummy $ enlace ip agregar enlace t-dummy nombre t-dummy.100 tipo vlan id 100 $ enlace ip agregar nombre t-nlmon tipo nlmon $ conjunto de enlaces ip t-nlmon master team0 $ conjunto de enlaces ip t-nlmon nomaster $ conjunto de enlaces ip t- dummy up $ ip link set team0 up $ ip link set t-dummy.100 down $ ip link set t-dummy.100 master team0 Cuando se esclaviza un dispositivo VLAN a un dispositivo de equipo y el tipo de dispositivo de equipo se cambia de no ether a ether, header_ops del dispositivo del equipo se cambia a vlan_header_ops. Eso es incorrecto y activará null-ptr-deref para vlan->real_dev en vlan_dev_hard_header() porque el dispositivo del equipo no es un dispositivo vlan. Almacene en caché eth_header_ops en team_setup(), luego asigne header_ops almacenados en caché a header_ops del dispositivo team net cuando su tipo cambie de no ether a ether para corregir el error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dccp: corrija dccp_v4_err()/dccp_v6_err() nuevamente dh->dccph_x es el noveno byte (desplazamiento 8) en "struct dccp_hdr", no en el "byte 7" como Jann reclamado. Necesitamos asegurarnos de que los mensajes ICMP sean lo suficientemente grandes, utilizando formas más estándar (sin más suposiciones). syzbot informó: ERROR: KMSAN: valor uninit en pskb_may_pull_reason include/linux/skbuff.h:2667 [en línea] ERROR: KMSAN: valor uninit en pskb_may_pull include/linux/skbuff.h:2681 [en línea] ERROR: KMSAN: uninit -valor en dccp_v6_err+0x426/0x1aa0 net/dccp/ipv6.c:94 pskb_may_pull_reason include/linux/skbuff.h:2667 [en línea] pskb_may_pull include/linux/skbuff.h:2681 [en línea] dccp_v6_err+0x426/0x1aa0 net/ dccp/ipv6.c:94 icmpv6_notify+0x4c7/0x880 net/ipv6/icmp.c:867 icmpv6_rcv+0x19d5/0x30d0 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6 /ip6_input.c:483 [en línea] NF_HOOK include/linux/netfilter.h:304 [en línea] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst .h:468 [en línea] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:304 [en línea] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net /core/dev.c:5523 [en línea] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637 netif_receive_skb_internal net/core/dev.c:5723 [en línea] netif_receive_skb+0x58/0x660 net/core/dev.c :5782 tun_rx_batched+0x83b/0x920 tun_get_user+0x564c/0x6940 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:1985 [en línea] new_sync_write fs /read_write.c:491 [en línea] vfs_write+0x8ef/0x15c0 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [en línea] __se_sys_write fs/read_write.c :646 [en línea] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+ 0x63/0xcd Uninit se creó en: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [en línea] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4 a0 neto/ core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [en línea] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6313 sock_alloc_send_pskb+ 0xa80/0xbf0 net/core/sock.c:2795 controladores tun_alloc_skb/net/tun.c:1531 [en línea] tun_get_user+0x23cf/0x6940 controladores/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 controladores/net/tun. c:2048 call_write_iter include/linux/fs.h:1985 [en línea] new_sync_write fs/read_write.c:491 [en línea] vfs_write+0x8ef/0x15c0 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c: 637 __do_sys_write fs/read_write.c:649 [en línea] __se_sys_write fs/read_write.c:646 [en línea] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd CPU: 0 PID: 4995 Comm: syz-executor153 Not tainted 6.6.0-rc1-syzkaller-00014-ga747acc0b752 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/08/2023

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/sgx: Resuelve reclamación SECS versus error de página para la ejecución EAUG. El recuperador SGX EPC (ksgxd) puede reclamar la página SECS EPC para un enclave y establecer secs.epc_page en NULL. La página SECS se utiliza para EAUG y ELDU en el controlador de fallas de la página SGX. Sin embargo, la verificación NULL para secs.epc_page solo se realiza para ELDU, no para EAUG, antes de usarse. Solucione este problema haciendo la misma verificación NULL y recargando la página SECS según sea necesario tanto para EAUG como para ELDU. La página SECS contiene metadatos del enclave global. Solo se puede reclamar cuando no quedan otras páginas del enclave. En ese punto, prácticamente no se puede hacer nada con el enclave hasta que se vuelva a paginar la página SECS. Un enclave no puede ejecutarse ni generar errores de página sin una página SECS residente. Pero aún es posible que un #PF para una página que no es SECS se compita con la paginación de la página SECS: cuando la última página A residente que no es SECS activa un #PF en una página B no residente, y luego la página A y Ambos SECS se paginan antes de que se maneje el #PF en B. Para solucionar este error es necesario que la ejecución se active con un #PF para EAUG. A continuación se muestra un rastro de cuando sucede. ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 RIP: 0010:sgx_encl_eaug_page+0xc7/0x210 Seguimiento de llamadas:? __kmem_cache_alloc_node+0x16a/0x440 ? xa_load+0x6e/0xa0 sgx_vma_fault+0x119/0x230 __do_fault+0x36/0x140 do_fault+0x12f/0x400 __handle_mm_fault+0x728/0x1110 handle_mm_fault+0x105/0x310 do_user_addr_fault+0x1ee/ 0x750? __this_cpu_preempt_check+0x13/0x20 exc_page_fault+0x76/0x180 asm_exc_page_fault+0x27/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: 8250_port: verifique los datos IRQ antes de usarlos. En caso de que el controlador hoja quiera usar el sondeo IRQ (irq = 0) y el registro IIR muestre que ocurrió una interrupción en el hardware 8250, el IRQ los datos pueden ser NULL. En tal caso, debemos omitir el evento de activación, ya que llegamos a este camino desde la interrupción del temporizador y es muy probable que el sistema ya esté despierto. Sin esta solución, tenemos un Ups: serial8250: ttyS0 en E/S 0x3f8 (irq = 0, base_baud = 115200) es un 16550A... ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000010 RIP: 0010:serial8250_handle_irq+0x7c/ 0x240 Seguimiento de llamadas: ? serial8250_handle_irq+0x7c/0x240? __pfx_serial8250_timeout+0x10/0x10

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bridge: use DEV_STATS_INC() syzbot/KCSAN informó ejecucións de datos en br_handle_frame_finish() [1] Esta función se puede ejecutar desde múltiples CPU sin exclusión mutua. Adopte DEV_STATS_INC() seguro para SMP para actualizar los campos dev->stats. Maneja las actualizaciones de dev->stats.tx_dropped mientras estamos en ello. [1] ERROR: KCSAN: ejecución de datos en br_handle_frame_finish / br_handle_frame_finish lectura-escritura en 0xffff8881374b2178 de 8 bytes por interrupción en la CPU 1: br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189 br_nf_hook_thresh+0x1ed/0x 220 br_nf_pre_routing_finish_ipv6+0x50f /0x540 NF_HOOK include/linux/netfilter.h:304 [en línea] br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178 br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508 nf_hook_entry_hoo kfn incluye/linux/netfilter. h:144 [en línea] nf_hook_bridge_pre net/bridge/br_input.c:272 [en línea] br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417 __netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417 __netif_receive_skb_one_core net / core/dev.c:5521 [en línea] __netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637 Process_backlog+0x21f/0x380 net/core/dev.c:5965 __napi_poll+0x60/0x3b0 net/core/dev.c :6527 napi_poll net/core/dev.c:6594 [en línea] net_rx_action+0x32b/0x750 net/core/dev.c:6727 __do_softirq+0xc1/0x265 kernel/softirq.c:553 run_ksoftirqd+0x17/0x20 kernel/softirq. c:921 smpboot_thread_fn+0x30a/0x4a0 kernel/smpboot.c:164 kthread+0x1d7/0x210 kernel/kthread.c:388 ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/ x86/entry/entry_64.S:304 lectura-escritura en 0xffff8881374b2178 de 8 bytes por interrupción en la CPU 0: br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189 br_nf_hook_thresh+0x1ed/0x220 br_nf_pre_routing_finish_ ipv6+0x50f/0x540 NF_HOOK incluye/ linux/netfilter.h:304 [en línea] br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178 br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508 nf_hook_entry_hookfn include/linux/netfilter. h:144 [en línea ] nf_hook_bridge_pre net/bridge/br_input.c: 272 [inline] br_handle_frame+0x4c9/0x940 net/bridge/br_input.c: 417 __netif_receive_skb_core+0xa8a/0x21e0 net/cors/dev.c: 5417 __netife_skbore dev.c :5521 [en línea] __netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637 Process_backlog+0x21f/0x380 net/core/dev.c:5965 __napi_poll+0x60/0x3b0 net/core/dev.c:6527 napi_poll net/ core/dev.c:6594 [en línea] net_rx_action+0x32b/0x750 net/core/dev.c:6727 __do_softirq+0xc1/0x265 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+ 0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [en línea] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [en línea] batadv_tt_local_purge+0x1a8/0x1f0 net/batman-adv/translation-table.c:1356 batadv_tt_purge+0x2b/0x630 net/batman-adv/translation-table.c:3560 Process_one_work kernel/workqueue.c:2630 [en línea] Process_scheduled_works+0x5b8 /0xa30 kernel/workqueue.c:2703 trabajador_thread+0x525/0x730 kernel/workqueue.c:2784 kthread+0x1d7/0x210 kernel/kthread.c:388 ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm +0x11/0x20 arch/x86/entry/entry_64.S:304 valor cambiado: 0x00000000000d7190 -> 0x00000000000d7191 Reportado por Kernel Concurrency Sanitizer en: CPU: 0 PID: 14848 Comm: kworker/u4:11 No contaminado 6.6.0-rc1 - syzkaller-00236-gad8a69f361b9 #0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: corrige memleak cuando caducan más de 255 elementos Cuando caducan más de 255 elementos, se supone que debemos cambiar a una nueva estructura de contenedor gc. Esto nunca sucede: el tipo u8 se ajustará antes de alcanzar el límite y nft_trans_gc_space() siempre devuelve verdadero. Esto significa que reciclamos la estructura inicial del contenedor gc y perdemos la pista de los elementos anteriores. Mientras lo hace, no elimine 'gc' después de que lo hayamos pasado a call_rcu.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/mm, kexec, ima: utilice memblock_free_late() desde ima_free_kexec_buffer(). El código que llama a ima_free_kexec_buffer() se ejecuta mucho después de que el asignador de memblock ya se haya eliminado, lo que podría provocar un Úselo después de forma gratuita en memblock_isolate_range(). Con KASAN o KFENCE, este Use After Free resultará en un ERROR de la tarea inactiva y un posterior pánico en el kernel. Cambie ima_free_kexec_buffer() a memblock_free_late() para evitar ese error.