Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries: aplica la validez y el tamaño del búfer de resultados de hcall plpar_hcall(), plpar_hcall9() y las funciones relacionadas esperan que los llamadores proporcionen búferes de resultados válidos de cierto tamaño mínimo. Actualmente esto se comunica sólo a través de comentarios en el código y el compilador no tiene idea. Por ejemplo, si escribo un error como este: long retbuf[PLPAR_HCALL_BUFSIZE]; // debería ser PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); Esto se compila sin emitir diagnósticos, pero probablemente da como resultado daños en la pila en tiempo de ejecución cuando plpar_hcall9() almacena los resultados más allá del final de la matriz. (Para ser claros, este es un ejemplo artificial y todavía no he encontrado una instancia real). Para hacer que esta clase de error sea menos probable, podemos usar parámetros de matriz de tamaño explícito en lugar de punteros en las declaraciones de las API hcall. Cuando se compila con -Warray-bounds[1], el código anterior ahora provoca un diagnóstico como este: error: el argumento de la matriz es demasiado pequeño; es de tamaño 32, el destinatario requiere al menos 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, | ^ ~~~~~~ [1] Habilitado para compilaciones LLVM pero no para GCC por ahora. Consulte El commit 0da6e5fd6c37 ("gcc: deshabilite '-Warray-bounds' para gcc-13 también") y relacionados cambios.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: shmem: corrige la obtención de lruvec incorrecto al reemplazar un folio de shmem Al probar shmem swapin, encontré la siguiente advertencia en mi máquina. La razón es que reemplazar una publicación shmem antigua por una nueva hace que mem_cgroup_migrate() borre los datos memcg de la publicación anterior. Como resultado, el folio antiguo no puede obtener el lruvec de memcg correcto necesario para eliminarse de la lista LRU cuando se libera. Esto podría provocar posibles problemas graves, como bloqueos de la lista de LRU debido a que se mantiene el bloqueo de LRU incorrecto y estadísticas de LRU incorrectas. Para solucionar este problema, podemos utilizar mem_cgroup_replace_folio() para reemplazar el antiguo folio shmem. [ 5241.100311] página: refcount:0 mapcount:0 mapeo:00000000000000000 index:0x0 pfn:0x5d9960 [ 5241.100317] head: orden:4 mapcount:0 complete_mapcount:0 nr_pages_mapped:0 pincount:0 [ 5241.100319] banderas: 17fffe0000040068(actualización|lru |head|swapbacked|node=0|zone=2|lastcpupid=0x3ffff) [ 5241.100323] raw: 17fffe0000040068 ffffdffd6687948 fffffdffd69ae008 0000000000000000 [ 5241.100325] raw: 0000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 5241.100326] cabeza: 17fffe0000040068 ffffdffd6687948 ffffdffd69ae008 000000000 [ 5241.100327] cabeza: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 5241.100328] cabeza: 17fffe0000000204 fffffdffd6665801 ffffffffffffffff 0000000000000000 [ 5241 .100329] encabezado: 0000000a00000010 0000000000000000 00000000ffffffff 0000000000000000 [5241.100330] página volcada porque: VM_WARN_ON_ONCE_FOLIO(!memcg &&!mem_cgroup_disable d()) [ 5241.100338] --------- ---[ cortar aquí ]------------ [ 5241.100339] ADVERTENCIA: CPU: 19 PID: 78402 en include/linux/memcontrol.h:775 folio_lruvec_lock_irqsave+0x140/0x150 [...] [ 5241.100374] pc : folio_lruvec_lock_irqsave+0x140/0x150 [ 5241.100375] lr : folio_lruvec_lock_irqsave+0x138/0x150 [ 5241.100376] sp : ffff80008b38b930 [...] [ 5241 .100398] Seguimiento de llamadas: [5241.100399] folio_lruvec_lock_irqsave+0x140/0x150 [5241.100401] __page_cache_release+ 0x90/0x300 [ 5241.100404] __folio_put+0x50/0x108 [ 5241.100406] shmem_replace_folio+0x1b4/0x240 [ 5241.100409] shmem_swapin_folio+0x314/0x528 [ 5241.1004 11] shmem_get_folio_gfp+0x3b4/0x930 [ 5241.100412] shmem_fault+0x74/0x160 [ 5241.100414] __do_fault+0x40/ 0x218 [ 5241.100417] do_shared_fault+0x34/0x1b0 [ 5241.100419] do_fault+0x40/0x168 [ 5241.100420] handle_pte_fault+0x80/0x228 [ 5241.100422] 0x1c4/0x440 [ 5241.100424] handle_mm_fault+0x60/0x1f0 [ 5241.100426] do_page_fault+0x120/0x488 [ 5241.100429] do_translation_fault+0x4c/0x68 [ 5241.100431] do_mem_abort+0x48/0xa0 [ 5241.100434] el0_da+0x38/0xc0 [ 5241.100436] [ 5241.100437] el0t_64_sync+0x14c/0x150 [ 5241.100439] ---[ final de seguimiento 00000000000000000 ] --- [baolin.wang@linux.alibaba.com: elimine los comentarios menos útiles, según Matthew] Enlace: https://lkml.kernel.org/r/ccad3fe1375b468ebca3227b6b729f3eaf9d8046.1718423197.git.baolin.wang@linux.alibaba. com

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: enorme_memoria: corrige el mapeo_grande_folio_support() mal utilizado para publicaciones anónimas Cuando hice una prueba de división de publicaciones grandes, apareció una ADVERTENCIA "[ 5059.122759][ T166] No se puede dividir la publicación del archivo en un valor distinto de 0 "orden" se activó. Pero los casos de prueba son sólo para folios anónimos. mientras que mapping_large_folio_support() solo es razonable para las publicaciones de caché de páginas. En split_huge_page_to_list_to_order(), la publicación pasó a mapping_large_folio_support(), tal vez una publicación anónima. Falta la verificación folio_test_anon(). Así que la división del THP anónimo fracasó. Esto también es lo mismo para shmem_mapping(). Será mejor que agreguemos un cheque para ambos. Pero shmem_mapping() en __split_huge_page() no está involucrado, ya que para las publicaciones anónimas, el parámetro final se establece en -1, por lo que (head[i].index >= end) siempre es falso. shmem_mapping() no se llama. También agregue un VM_WARN_ON_ONCE() en mapping_large_folio_support() para un mapeo anónimo, para que podamos detectar el uso incorrecto más fácilmente. Es posible que existan publicaciones de THP en el caché de páginas, incluso si el sistema de archivos no admite publicaciones grandes, esto se debe a que cuando CONFIG_TRANSPARENT_HUGEPAGE está habilitado, khugepaged intentará colapsar las páginas respaldadas por archivos de solo lectura en THP. Pero el mapeo en realidad no admite correctamente folios grandes de varios pedidos. Usando /sys/kernel/debug/split_huge_pages para verificar esto, con este parche, un THP anónimo grande se divide con éxito y la advertencia cesa.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: corrige la desreferencia del puntero NULL en ocfs2_abort_trigger() bdev->bd_super se ha eliminado y el commit 8887b94d9322 cambia el uso de bdev->bd_super a b_assoc_map->host->i_sb. Dado que ocfs2 no ha configurado bh->b_assoc_map, activará la desreferencia del puntero NULL al llamar a ocfs2_abort_trigger(). En realidad, esto se señaló en la historia, consulte el commit 74e364ad1b13. Pero cometí un error al revisar el commit 8887b94d9322 y luego reintroducir esta regresión. Dado que no podemos reactivar bdev en el encabezado del búfer, solucione este problema inicializando todos los tipos de activadores de ocfs2 cuando complete el super, y luego obtenga el activador de ocfs2 específico de ocfs2_caching_info cuando acceda al diario. [joseph.qi@linux.alibaba.com:v2] Enlace: https://lkml.kernel.org/r/20240602112045.1112708-1-joseph.qi@linux.alibaba.com

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; }