Vulnerabilidades

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: gtp: corrige use-after-free y null-ptr-deref en gtp_newlink() La estructura de operaciones gtp_link_ops para el subSYSTEM debe registrarse después de registrar la estructura de operaciones pernet gtp_net_ops. Syzkaller encontró el error 'fallo de protección general en gtp_genl_dump_pdp': [1010.702740] gtp: módulo GTP descargado [1010.715877] fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [1010.715888 ] KASAN: ptr nulo -deref en el rango [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out No contaminado 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Nombre de hardware: Estándar QEMU PC (Q35+ ICH9, 2009), BIOS 1.16.0-alt1 01/04/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Código: 80 3c 02 00 0f 85 41 04 00 0 0 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 4 8b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000 000 [ 1010.715933] RDX: 00000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 000000000000 0001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 00000000000 00000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555 554 [1010.715972] Seguimiento de llamadas: [1010.715985]? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [1010.716002]? exc_general_protection+0x199/0x2f0 [1010.716016]? asm_exc_general_protection+0x1e/0x30 [1010.716026]? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0 [1010.716063]? is_bpf_text_address+0xc0/0x1f0 [1010.716070]? kernel_text_address.part.0+0xbb/0xd0 [1010.716076]? __kernel_text_address+0x56/0xa0 [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0 [1010.716091]? create_prof_cpu_mask+0x30/0x30 [1010.716098]? arch_stack_walk+0x9e/0xf0 [1010.716106]? stack_trace_save+0x91/0xd0 [1010.716113]? stack_trace_consume_entry+0x170/0x170 [1010.716121]? __lock_acquire+0x15c5/0x5380 [1010.716139]? mark_held_locks+0x9e/0xe0 [1010.716148]? ¿kmem_cache_alloc_trace+0x35f/0x3c0 [1010.716155]? __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [1010.716179]? lock_acquire+0x1fe/0x560 [1010.716188]? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196] netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [1010.716208]? netlink_ack+0xab0/0xab0 [1010.716213]? netlink_deliver_tap+0x202/0xd50 [1010.716220]? netlink_deliver_tap+0x218/0xd50 [1010.716226]? __virt_addr_valid+0x30b/0x590 [ 1010.716233] netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [1010.716248]? __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ? netlink_unicast+0x800/0x800 [1010.716269]? __import_iovec+0x292/0x510 [ 1010.716276] ? netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290] ____sys_sendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [1010.716304]? __ia32_sys_recvmmsg+0x270/0x270 [1010.716309]? lock_acquire+0x1fe/0x560 [1010.716315]? Drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170 [1010.716337]? lockdep_init_map ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige la ejecución entre la finalización de extensión ordenada y fiemap Para fiemap recientemente dejamos de bloquear el rango de extensión objetivo durante toda la duración de la llamada a fiemap, para evitar un punto muerto en un escenario donde el búfer fiemap resulta ser un rango mapeado en memoria del mismo archivo. Es muy poco probable que este caso de uso sea útil en la práctica, pero puede activarse mediante pruebas difusas (syzbot, etc.). Sin embargo, al no bloquear el rango de extensión objetivo durante toda la duración de la llamada a fiemap, podemos competir con una extensión ordenada. Esto sucede así: 1) La tarea fiemap termina de procesar un elemento de extensión de archivo que cubre el rango de archivos [512K, 1M[, y ese elemento de extensión de archivo es el último elemento de la hoja que se está procesando actualmente; 2) Y la extensión ordenada para el rango de archivos [768K, 2M[, en modo COW, se completa (btrfs_finish_one_ordered()) y el elemento de extensión de archivo que cubre el rango [512K, 1M[ se recorta para cubrir el rango [512K, 768K[ y luego se inserta un nuevo elemento de extensión de archivo para el rango [768K, 2M[ en el árbol de subvolumen del inodo; 3) La tarea fiemap llama a fiemap_next_leaf_item(), que luego llama a btrfs_next_leaf() para encontrar la siguiente hoja/elemento. Esto encuentra que la siguiente clave después de la que procesamos anteriormente (su tipo es BTRFS_EXTENT_DATA_KEY y su desplazamiento es 512K), es la clave correspondiente al nuevo elemento de extensión de archivo insertado por la extensión ordenada, que tiene un tipo de BTRFS_EXTENT_DATA_KEY y un desplazamiento de 768K; 4) Más tarde, el código fiemap termina en emit_fiemap_extent() y activa la advertencia: if (cache->offset + cache->len > offset) { WARN_ON(1); devolver -EINVAL; } Dado que obtenemos 1M > 768K, porque la entrada emitida previamente para la extensión anterior que cubre el rango de archivos [512K, 1M[ termina en un desplazamiento que es mayor que el desplazamiento inicial de la nueva extensión (768K). Esto hace que fiemap falle con -EINVAL además de activar la advertencia que produce un seguimiento de pila como el siguiente: [1621.677651] ------------[ cortar aquí ]----------- - [1621.677656] ADVERTENCIA: CPU: 1 PID: 204366 en fs/btrfs/extent_io.c:2492 emit_fiemap_extent+0x84/0x90 [btrfs] [1621.677899] Módulos vinculados en: btrfs blake2b_generic (...) [1621.677951] CPU: 1 PID: 204366 Comm: pool No contaminado 6.8.0-rc5-btrfs-next-151+ #1 [1621.677954] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390- prebuilt.qemu.org 01/04/2014 [1621.677956] RIP: 0010:emit_fiemap_extent+0x84/0x90 [btrfs] [1621.678033] Código: 2b 4c 89 63 (...) [1621.678035] RSP: 0018:ffffab160 89ffd20 EFLAGS: 00010206 [1621.678037] RAX: 00000000004fa000 RBX: ffffab16089ffe08 RCX: 0000000000009000 [1621.678039] RDX: 00000000004f9000 RSI: 00000000004f1000 RDI : ffffab16089ffe90 [1621.678040] RBP: 00000000004f9000 R08: 0000000000001000 R09: 00000000000000000 [1621.678041] R10: 0000000000000000 R11 : 0000000000001000 R12: 0000000041d78000 [1621.678043 ] R13: 0000000000001000 R14: 00000000000000000 R15: ffff9434f0b17850 [1621.678044] FS: 00007fa6e20006c0(0000) GS:ffff943bdfa40000(0000) kn lGS:0000000000000000 [1621.678046] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1621.678048] CR2: 00007fa6b0801000 CR3 : 000000012d404002 CR4: 0000000000370ef0 [1621.678053] DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 [1621.678055] DR 3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1621.678056] Seguimiento de llamadas: [1621.678074] [1621.678076] ? __advertir+0x80/0x130 [1621.678082] ? emit_fiemap_extent+0x84/0x90 [btrfs] [1621.678159] ? report_bug+0x1f4/0x200 [1621.678164] ? ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: Sparse-Memory/vmemmap fuera de los límites corrige Offset vmemmap para que la primera página de vmemmap se asigne a la primera página de la memoria física para garantizar que vmemmap Los límites se respetarán durante las operaciones pfn_to_page()/page_to_pfn(). Las macros de conversión producirán direcciones SV39/48/57 correctas para cada DRAM_BASE posible/válida dentro de los límites de la memoria física. v2: Abordar los comentarios de Alex

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: controladores: perf: ctr_get_width la función para legado no está definida Con los parámetros CONFIG_RISCV_PMU_LEGACY=y y CONFIG_RISCV_PMU_SBI=n el kernel de Linux falla cuando intenta el registro de rendimiento: $ perf record ls [ 46.749286] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 [ 46.750199] Ups [#1] [ 46.750342] Módulos vinculados en: [ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2 [ 46.750906] Nombre del hardware : riscv-virtio,qemu (DT) [ 46.751184] epc : 0x0 [ 46.751430 ] ra : arch_perf_update_userpage+0x54/0x13e [ 46.751680] epc : 00000000000000000 ra : ffffffff8072ee52 sp : ff20000 00022b8f0 [46.751958] gp: ffffffff81505988 tp: ff6000000290d400 t0: ff2000000022b9c0 [ 46.752229] t1 : 0000000000000001 t2 : 0000000000000003 s0 : ff2000000022b930 [ 46.752451] s1 : ff600000028fb000 a0 : 0000000000000000 a 1: ff600000028fb000 [46.752673] a2: 0000000ae2751268 a3: 00000000004fb708 a4: 00000000000000004 [46.752895] a5: 0000000000000000 a6: 000000000017ffe3 a7: 00000000000000d2 [46.753117] s2: ff600000028fb000 s3: 0000000ae2751268 s4: 0000000000000000 [46.753338] s5: ffffffff8153e290 s6: ff600000863b9000 s7: ff60000002 961078 [46.753562] s8: ff60000002961048 s9: ff60000002961058 s10: 00000000000000001 [46.753783] s11: 0000000000000018 t3: ffffffffffffff ff t4 : ffffffffffffffff [ 46.754005] t5 : ff6000000292270c t6: ff2000000022bb30 [46.754179] estado: 0000000200000100 badaddr: 00000000000000000 causa: 0000000000000000c [46.754653] Código: No se puede acceder instrucción en 0xffffffffffffffec. [ 46.754939] ---[ end trace 0000000000000000 ]--- [ 46.755131] nota: perf-exec[107] salió con irqs deshabilitados [ 46.755546] nota: perf-exec[107] salió con preempt_count 4 Esto sucede porque en el legado En este caso, la función ctr_get_width no se definió, pero se usa en arch_perf_update_userpage. También elimine el control adicional en riscv_pmu_ctr_get_width_mask

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Previene un posible desbordamiento del búfer en map_hw_resources Agrega una verificación en la función map_hw_resources para evitar un posible desbordamiento del búfer. La función accedía a matrices utilizando un índice que potencialmente podría ser mayor que el tamaño de las matrices, lo que provocaba un desbordamiento del búfer. Agrega una verificación para garantizar que el índice esté dentro de los límites de las matrices. Si el índice está fuera de los límites, se imprime un mensaje de error y, al interrumpirlo, continuará la ejecución ignorando los datos adicionales antes de tiempo para evitar el desbordamiento del búfer. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:79 error map_hw_resources(): desbordamiento del búfer 'dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_stream_id' 6 <= 7 controladores/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:81 error map_hw_resources(): desbordamiento del búfer 'dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_plane_id' 6 <= 7

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: qcom: corrige el puntero no inicializado dmactl. En el caso de que se llame a __lpass_get_dmactl_handle y el ID del controlador dai_id no sea válido, al puntero dmactl no se le asigna un valor y dmactl contiene un valor basura. ya que no se ha inicializado y, por lo tanto, es posible que la verificación nula no funcione. Solucione esto para inicializar dmactl a NULL. Se podría argumentar que los compiladores modernos establecerán esto en cero, pero es útil mantenerlo inicializado de la misma manera en las funciones __lpass_platform_codec_intf_init y lpass_cdc_dma_daiops_hw_params. Limpia la advertencia de compilación de escaneo clang: sound/soc/qcom/lpass-cdc-dma.c:275:7: advertencia: la condición de rama se evalúa como un valor basura [core.uninitialized.Branch]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/vmscan: corrige un error al llamar a wakeup_kswapd() con un índice de zona incorrecto Con el equilibrio numa activado, cuando se ejecuta un SYSTEM numa donde un nodo numa no tiene su memoria local por lo que no tiene zonas administradas, se ha observado lo siguiente. Es porque se llama a wakeup_kswapd() con un índice de zona incorrecto, -1. Se solucionó verificando el índice antes de llamar a wakeup_kswapd(). > ERROR: no se puede manejar el error de página para la dirección: 00000000000033f3 > #PF: acceso de lectura del supervisor en modo kernel > #PF: error_code(0x0000) - página no presente > PGD 0 P4D 0 > Ups: 0000 [#1] SMP PREEMPT NOPTI > CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255 > Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS > rel-1.16.0-0-gd239552ce722-prebuilt.qemu .org 01/04/2014 > RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812) > Código: (omitido) > RSP: 0000:ffffc90004257d58 EFLAGS: 00010286 > RAX: ffffffffffffffff RBX: ffff88883f ff0480RCX: 0000000000000003 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88883fff0480 > RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff > R10: ff ff888106c95540 R11: 0000000055555554 R12: 0000000000000003 > R13: 0000000000000000 R14: 00000000000000000 R15: ffff88883fff0940 > FS: 0000 7fc4b8124740(0000) GS: ffff888827c00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000033f3 CR3: 000000026cc08004 CR4: 0000000000770ee0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 000 0000000000400 > PKRU: 55555554 > Rastreo de llamadas: > > ? __morir > ? page_fault_oops > ? __pte_offset_map_lock > ? exc_page_fault > ? asm_exc_page_fault > ? wakeup_kswapd > migrar_misplaced_page > __handle_mm_fault > handle_mm_fault > do_user_addr_fault > exc_page_fault > asm_exc_page_fault > RIP: 0033:0x55b897ba0808 > Código: (omitido) > RSP: 002b:00007ffeefa821a0 EFLAGS: 00 010287 > RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0 > RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0 > RBP: 00007ffeefa821a0 R08: 0000000000000037 R09: 00000000000000075 > R10: 0000000000000000 R11: 0 000000000000202 R12: 0000000000000000 > R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000 >

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fbcon: restaurar siempre los datos de fuentes antiguos en fbcon_do_set_font() commit a5a923038d70 (fbdev: fbcon: revertir correctamente los cambios cuando falló vc_resize()) comenzó a restaurar los datos de fuentes antiguos en caso de falla (de vc_resize ()). Pero funciona sólo para fuentes de usuario. Significa que las fuentes internas/del "SYSTEM" no se restauran en absoluto. Entonces, como resultado, la primera llamada a fbcon_do_set_font() no realiza ninguna restauración al fallar vc_resize(). Syzkaller puede reproducir esto para bloquear el SYSTEM en la siguiente invocación de font_get(). Es bastante difícil solucionar el error de asignación en vc_resize() en el primer font_set(), pero no imposible. Esp. si se utiliza la inyección de fallos para ayudar en la ejecución/fallo. Sirius lo demostró: ERROR: no se puede manejar el error de página para la dirección: fffffffffffffff8 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Ups: 0000 [ #1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc No contaminado 6.7.0-g9d1694dc91ce #20 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1 01/04/2014 RIP : 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Seguimiento de llamadas: con_font_get drivers/tty/vt/vt.c:4558 [en línea] con_font_op+0x1fc/0xf20 drivers/tty /vt/vt.c:4673 controladores vt_k_ioctl/tty/vt/vt_ioctl.c:474 [en línea] vt_ioctl+0x632/0x2ec0 controladores/tty/vt/vt_ioctl.c:752 tty_ioctl+0x6f8/0x1570 controladores/tty/tty_io. c:2803 vfs_ioctl fs/ioctl.c:51 [en línea] ... Así que restaure los datos de fuente en cualquier caso, no solo para las fuentes del usuario. Tenga en cuenta que el 'if' posterior ahora está protegido por 'old_userfont' y no por 'old_data' ya que este último siempre está configurado ahora. (Y se supone que no es NULL. De lo contrario, volveríamos a ver el error anterior).

El control de acceso incorrecto en ITB-GmbH TradePro v9.5 permite a atacantes remotos recibir todas las confirmaciones de pedidos de la tienda en línea a través del complemento printmail.

Vulnerabilidad de inyección SQL en ITB-GmbH TradePro v9.5, permite a atacantes remotos ejecutar consultas SQL a través del componente oordershow en la función de cliente.

La versión 6.5.19 y anteriores de Adobe Experience Manager se ven afectadas por una vulnerabilidad de Cross Site Scripting (XSS) basada en DOM que podría ser aprovechada por un atacante con pocos privilegios para inyectar scripts maliciosos en páginas web vulnerables. Se puede ejecutar JavaScript malicioso en el navegador de la víctima cuando navega a la página que contiene el script vulnerable. Esto podría resultar en la ejecución de código arbitrario dentro del contexto del navegador de la víctima.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/pseries/iommu: la tabla IOMMU no está inicializada para kdump sobre SR-IOV Cuando el kernel de kdump intenta copiar datos de volcado sobre SR-IOV, LPAR entra en pánico debido a una excepción de puntero NULL: El kernel intentó leer la página del usuario (0): ¿intento de explotación? (uid: 0) ERROR: Desreferencia del puntero NULL del kernel al leer en0x00000000 Faulting instruction address: 0xc000000020847ad4 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12 Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+) MSR: 800000000280b033 CR: 48288244 XER: 00000008 CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1 ... NIP _find_next_zero_bit+0x24/0x110 LR bitmap_find_next_zero_area_off+0x5c/0xe0 Call Trace: dev_printk_emit+0x38/0x48 (unreliable) iommu_area_alloc+0xc4/0x180 iommu_range_alloc+0x1e8/0x580 iommu_alloc+0x60/0x130 iommu_alloc_coherent+0x158/0x2b0 dma_iommu_alloc_coherent+0x3c/0x50 dma_alloc_attrs+0x170/0x1f0 mlx5_cmd_init+0xc0/0x760 [mlx5_core] mlx5_function_setup+0xf0/0x510 [mlx5_core] mlx5_init_one+0x84/0x210 [mlx5_core] probe_one+0x118/0x2c0 [mlx5_core] local_pci_probe+0x68/0x110 pci_call_probe+0x68/0x200 pci_device_probe+0xbc/0x1a0 really_probe+0x104/0x540 __driver_probe_device+0xb4/0x230 driver_probe_device+0x54/0x130 __driver_attach+0x158/0x2b0 bus_for_each_dev+0xa8/0x130 driver_attach+0x34/0x50 bus_add_driver+0x16c/0x300 driver_register+0xa4/0x1b0 __pci_register_driver+0x68/0x80 mlx5_init+0xb8/0x100 [mlx5_core] do_one_initcall+0x60/0x300 do_init_module+0x7c/0x2b0. En el momento del volcado de LPAR, antes de que kexec entregue el control al kernel de kdump, los DDW (Dynamic DMA Windows) se escanean y agregan al FDT. Para el caso de SR-IOV, la ventana DMA predeterminada "ibm,dma-window" se elimina de FDT y se agrega DDW para el dispositivo. Ahora, kexec entrega el control al kernel kdump. Cuando se inicializa el kernel kdump, se escanean los buses PCI y se crean grupos/tablas IOMMU, en pci_dma_bus_setup_pSeriesLP(). Para el caso SR-IOV, no existe "ibm,dma-window". el commit original: b1fc44eaa9ba, corrige la ruta donde la memoria está preasignada (asignada directamente) al DDW. Cuando las TCE se asignan directamente, no es necesario inicializar las tablas IOMMU. iommu_table_setparms_lpar() solo considera la propiedad "ibm,dma-window" al inicializar la tabla IOMMU. En el escenario en el que las TCE se asignan dinámicamente para SR-IOV, la tabla IOMMU recién creada no se inicializa. Más tarde, cuando el controlador del dispositivo intenta ingresar TCE para el dispositivo SR-IOV, se genera una ejecución de puntero NULL desde iommu_area_alloc(). La solución es inicializar la tabla IOMMU con la propiedad DDW almacenada en el FDT. Hay 2 puntos para recordar: 1. Para el adaptador dedicado, el kernel de kdump encontraría tanto el valor predeterminado como el DDW en FDT. En este caso, la propiedad DDW se utiliza para inicializar la tabla IOMMU. 2. Un DDW podría tener un mapeo directo o dinámico. El kernel kdump inicializaría la tabla IOMMU y marcaría el DDW existente como "dinámico". Esto funciona bien ya que, en el momento de la inicialización de la tabla, iommu_table_clear() crea algo de espacio en el DDW, para una cantidad predefinida de TCE que son necesarias para que kdump tenga éxito.