Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arch/arm64: Corregir la inicialización de la topología para la programación del núcleo Los sistemas Arm64 dependen de store_cpu_topology() para llamar a update_siblings_masks() para transferir la topología a las distintas máscaras de CPU. Esto debe hacerse antes de la llamada a notify_cpu_starting() que le informa al programador sobre cada CPU encontrada, de lo contrario, las estructuras de datos de programación del núcleo se configuran de una manera que no coincide con la topología real. Con smt_mask no configurado correctamente, abandonamos `cpumask_weight(smt_mask) == 1` para !leaders en: notify_cpu_starting() cpuhp_invoke_callback_range() sched_cpu_starting() sched_core_cpu_starting() lo que lleva a que rq->core no se configure correctamente para !leader-rq. Sin este cambio, stress-ng (que permite la programación del núcleo en sus pruebas prctl en versiones más nuevas, es decir, con soporte PR_SCHED_CORE) provoca una advertencia y luego un bloqueo (recortado para mayor legibilidad): [ 1853.805168] ------------[ cortar aquí ]------------ [ 1853.809784] task_rq(b)->core != rq->core [ 1853.809792] ADVERTENCIA: CPU: 117 PID: 0 en kernel/sched/fair.c:11102 cfs_prio_less+0x1b4/0x1c4 ... [ 1854.015210] No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000010 ... [ 1854.231256] Rastreo de llamadas: [ 1854.233689] pick_next_task+0x3dc/0x81c [ 1854.237512] __schedule+0x10c/0x4cc [ 1854.240988] schedule_idle+0x34/0x54

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/imx: Se corrige la pérdida de memoria en imx_pd_connector_get_modes Evita la pérdida de la variable de modo de visualización si falla of_get_drm_display_mode. Addresses-Coverity-ID: 1443943 ("Fuga de recursos")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ipv4: fix route with nexthop object delete Warning La gente de FRR se ha encontrado con una advertencia del kernel[1] al eliminar rutas[2] que se produce al intentar eliminar una ruta que apunta a un id de nexthop sin especificar nhid pero que coincide con una interfaz. Es decir, se encuentra una ruta pero nos encontramos con una advertencia al hacerla coincidir. La advertencia es de fib_info_nh() en include/net/nexthop.h porque la ejecutamos en un fib_info con un objeto nexthop. La cadena de llamadas es: inet_rtm_delroute -> fib_table_delete -> fib_nh_match (llamado con un fib_info de nexthop y también con fc_oif establecido, llamando así a fib_info_nh en el fib_info y activando la advertencia). La solución es no hacer ninguna coincidencia en esa rama si el fi tiene un objeto nexthop porque se gestionan por separado. Es decir, deberíamos coincidir al eliminar sin especificación nh y deberíamos fallar al eliminar una ruta de siguiente salto con especificación nh de estilo antiguo porque los objetos de siguiente salto se administran por separado, por ejemplo: $ ip r show 1.2.3.4/32 1.2.3.4 nhid 12 via 192.168.11.2 dev dummy0 $ ip r del 1.2.3.4/32 $ ip r del 1.2.3.4/32 nhid 12 $ ip r del 1.2.3.4/32 dev dummy0 [1] [ 523.462226] ------------[ cut here ]------------ [ 523.462230] ADVERTENCIA: CPU: 14 PID: 22893 en include/net/nexthop.h:468 fib_nh_match+0x210/0x460 [ 523.462236] Modules linked in: dummy rpcsec_gss_krb5 xt_socket nf_socket_ipv4 nf_socket_ipv6 ip6table_raw iptable_raw bpf_preload xt_statistic ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs xt_mark nf_tables xt_nat veth nf_conntrack_netlink nfnetlink xt_addrtype br_netfilter overlay dm_crypt nfsv3 nfs fscache netfs vhost_net vhost vhost_iotlb tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack 8021q garp mrp ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bridge stp llc rfcomm snd_seq_dummy snd_hrtimer rpcrdma rdma_cm iw_cm ib_cm ib_core ip6table_filter xt_comment ip6_tables vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) qrtr bnep binfmt_misc xfs vfat fat squashfs loop nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(POE) nvidia(POE) intel_rapl_msr intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi btusb btrtl iwlmvm uvcvideo btbcm snd_hda_intel edac_mce_amd [ 523.462274] videobuf2_vmalloc videobuf2_memops btintel snd_intel_dspcfg videobuf2_v4l2 snd_intel_sdw_acpi bluetooth snd_usb_audio snd_hda_codec mac80211 snd_usbmidi_lib joydev snd_hda_core videobuf2_common kvm_amd snd_rawmidi snd_hwdep snd_seq videodev ccp snd_seq_device libarc4 ecdh_generic mc snd_pcm kvm iwlwifi snd_timer drm_kms_helper snd cfg80211 cec soundcore irqbypass rapl wmi_bmof i2c_piix4 rfkill k10temp pcspkr acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc drm zram ip_tables crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel nvme sp5100_tco r8169 nvme_core wmi ipmi_devintf ipmi_msghandler fuse [ 523.462300] CPU: 14 PID: 22893 Comm: ip Tainted: P OE 5.16.18-200.fc35.x86_64 #1 [ 523.462302] Nombre del hardware: Micro-Star International Co., Ltd. MS-7C37/MPG X570 GAMING EDGE WIFI (MS-7C37), BIOS 1.C0 29/10/2020 [ 523.462303] RIP: 0010:fib_nh_match+0x210/0x460 [ 523.462304] Código: 7c 24 20 48 8b b5 90 00 00 00 e8 bb ee f4 ff 48 8b 7c 24 20 41 89 c4 e8 ee eb f4 ff 45 85 e4 0f 85 2e fe ff ff e9 4c ff ff ff <0f> 0b e9 17 ff ff ff 3c 0a 0f 85 61 fe ff ff 48 8b b5 98 00 00 00 [ 523.462306] RSP: 0018:ffffaa53d4d87928 EFLAGS: 00010286 [ 523.462307] RAX: 000000000000000 RBX: ffffaa53d4d87a90 RCX: ffffaa53d4d87bb0 [ 523.462308] RDX: ffff9e3d2ee6be80 RSI: ffffaa53d4d87a90 RDI: ffffffff920ed380 [ 523.462309] RBP: ffff9e3d2ee6be80 R08: 0000000000000064 R09: 0000000000000000 [ 523.462310] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000031 [ 523.462310] R13: 0000000000000020 R14: 00000000 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: skbuff: corrección de coalescencia para reciclaje de fragmentos de page_pool Corrige un use-after-free al usar page_pool con fragmentos de página. Encontramos este problema durante RX normal en el controlador hns3: (1) Inicialmente tenemos tres descriptores en la cola RX. El primero asigna PAGE1 a través de page_pool, y los otros dos asignan la mitad de PAGE2 cada uno. Las referencias de página se ven así: RX_BD1 _______ PAGE1 RX_BD2 _______ PAGE2 RX_BD3 _________/ (2) Manejar RX en el primer descriptor. Asignar SKB1, eventualmente agregado a la cola de recepción por tcp_queue_rcv(). (3) Manejar RX en el segundo descriptor. Asigne SKB2 y páselo a netif_receive_skb(): netif_receive_skb(SKB2) ip_rcv(SKB2) SKB3 = skb_clone(SKB2) SKB2 y SKB3 comparten una referencia a PAGE2 a través de skb_shinfo()->dataref. La otra referencia a PAGE2 todavía la mantiene RX_BD3: SKB2 ---+- PAGE2 SKB3 __/ / RX_BD3 _________/ (3b) Ahora, mientras maneja TCP, fusione SKB3 con SKB1: tcp_v4_rcv(SKB3) tcp_try_coalesce(to=SKB1, from=SKB3) // tiene éxito kfree_skb_partial(SKB3) skb_release_data(SKB3) // elimina una referencia de datos SKB1 _____ PAGE1 \____ SKB2 _____ PAGE2 / RX_BD3 _________/ En skb_try_coalesce(), __skb_frag_ref() toma una referencia de página a PAGE2, donde en cambio debería haber aumentado la referencia de fragmento de page_pool, pp_frag_count. Sin la fusión, al liberar SKB2 y SKB3, se eliminaría una única referencia a PAGE2. Ahora, al liberar SKB1 y SKB2, se descartarán dos referencias a PAGE2, lo que provocará un desbordamiento. (3c) Descartar SKB2: af_packet_rcv(SKB2) consume_skb(SKB2) skb_release_data(SKB2) // descarta la segunda referencia de datos page_pool_return_skb_page(PAGE2) // descarta una pp_frag_count SKB1 _____ PAGE1 \____ PAGE2 / RX_BD3 _________/ (4) El espacio de usuario llama a recvmsg() Copia SKB1 y lo libera. Dado que SKB3 se fusionó con SKB1, también liberamos la página SKB3: tcp_eat_recv_skb(SKB1) skb_release_data(SKB1) page_pool_return_skb_page(PAGE1) page_pool_return_skb_page(PAGE2) // elimina el segundo pp_frag_count (5) PAGE2 se libera, ¡pero el tercer descriptor RX todavía lo estaba usando! En nuestro caso, esto causa fallas de IOMMU, pero corrompería silenciosamente la memoria si IOMMU estuviera deshabilitado. Cambie la lógica que verifica si los SKB pp_recycle se pueden fusionar. Aún rechazamos diferentes pp_recycle entre SKB 'from' y 'to', pero para evitar la situación descrita anteriormente, también rechazamos la fusión cuando tanto 'from' como 'to' son pp_recycled y 'from' es clonado. La nueva lógica permite fusionar un SKB pp_recycle clonado en uno con referencia de página, porque en este caso la versión (4) eliminará la referencia correcta, la tomada por skb_try_coalesce().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/tls: corrige el error de slab fuera de los límites en decrypt_internal El tamaño de memoria de tls_ctx->rx.iv para AES128-CCM es 12 configurado en tls_set_sw_offload(). El valor de retorno de crypto_aead_ivsize() para "ccm(aes)" es 16. Por lo tanto, memcpy() requiere 16 bytes de 12 bytes de espacio de memoria y activará un error de losa fuera de los límites de la siguiente manera: ========================================================================= ERROR: KASAN: losa fuera de los límites en decrypt_internal+0x385/0xc40 [tls] Lectura de tamaño 16 en la dirección ffff888114e84e60 por la tarea tls/10911 Seguimiento de llamadas: dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db ? decrypt_internal+0x385/0xc40 [tls] kasan_report+0xab/0x120 ? decrypt_internal+0x385/0xc40 [tls] kasan_check_range+0xf9/0x1e0 memcpy+0x20/0x60 decrypt_internal+0x385/0xc40 [tls] ? tls_get_rec+0x2e0/0x2e0 [tls] ? process_rx_list+0x1a5/0x420 [tls] ? tls_setup_from_iter.constprop.0+0x2e0/0x2e0 [tls] decrypt_skb_update+0x9d/0x400 [tls] tls_sw_recvmsg+0x3c8/0xb50 [tls] Asignado por la tarea 10911: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 tls_set_sw_offload+0x2eb/0xa20 [tls] tls_setsockopt+0x68c/0x700 [tls] __sys_setsockopt+0xfe/0x1b0 Reemplace crypto_aead_ivsize() con prot->iv_size + prot->salt_size cuando el valor iv de memcpy() esté en Escenario TLS_1_3_VERSION.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: zorro7xx: Se corrige una pérdida de recursos en zorro7xx_remove_one() La ruta de manejo de errores de la sonda libera un recurso que no se libera en la función de eliminación. En algunos casos, se debe deshacer una operación ioremap(). Agregue la llamada iounmap() que falta en la función de eliminación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmmremap.c: evitar invalidate_range_start/end inútil en mremap(old_size=0) Si una llamada al sistema mremap() con old_size=0 termina en move_page_tables(), llamará a invalidate_range_start()/invalidate_range_end() innecesariamente, es decir, con un rango vacío. Esto provoca una ADVERTENCIA en mmu_notifier de KVM. En el pasado, se ha diagnosticado que los rangos vacíos eran errores con un desfase de uno, de ahí la ADVERTENCIA. Dado el bajo número (hasta ahora) de informes únicos, los beneficios de detectar más llamadores con errores parecen superar el costo de tener que arreglar casos como este, donde el espacio de usuario está haciendo algo tonto. En este caso particular, un retorno temprano de move_page_tables() es suficiente para solucionar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: atravesar dispositivos bajo chunk_mutex en btrfs_can_activate_zone btrfs_can_activate_zone() se puede llamar con el device_list_mutex ya retenido, lo que provocará un bloqueo: insert_dev_extents() // Toma device_list_mutex `-> insert_dev_extent() `-> btrfs_insert_empty_item() `-> btrfs_insert_empty_items() `-> btrfs_search_slot() `-> btrfs_cow_block() `-> __btrfs_cow_block() `-> btrfs_alloc_tree_block() `-> btrfs_reserve_extent() `-> find_free_extent() `-> find_free_extent_update_loop() `-> can_allocate_chunk() `-> btrfs_can_activate_zone() // Toma device_list_mutex nuevamente En lugar de usar la RCU en fs_devices->device_list podemos usar fs_devices->alloc_list, protegido por chunk_mutex para recorrer la lista de dispositivos activos. Estamos en el hilo de asignación de fragmentos. La asignación de fragmentos más nueva ocurre desde los dispositivos en fs_device->alloc_list protegidos por chunk_mutex. btrfs_create_chunk() lockdep_assert_held(&info->chunk_mutex); gather_device_info list_for_each_entry(device, &fs_devices->alloc_list, dev_alloc_list) Además, un dispositivo que reaparece después del montaje no se unirá a alloc_list todavía y estará en dev_list, que no queremos considerar en el contexto de la asignación de fragmentos. [15.166572] ADVERTENCIA: se detectó un posible bloqueo recursivo [15.167117] 5.17.0-rc6-dennis #79 No contaminado [15.167487] -------------------------------------------- [15.167733] kworker/u8:3/146 está intentando adquirir el bloqueo: [15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, en: find_free_extent+0x15a/0x14f0 [btrfs] [15.167733] [15.167733] pero la tarea ya tiene el bloqueo: [15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, en: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs] [15.167733] [15.167733] otra información que podría ayudarnos a depurar esto: [15.167733] Posible escenario de bloqueo inseguro: [15.167733] [15.171834] CPU0 [15.171834] ---- [15.171834] lock(&fs_devs->device_list_mutex); [15.171834] lock(&fs_devs->device_list_mutex); [15.171834] [15.171834] *** BLOQUEO INTERMEDIO *** [15.171834] [15.171834] Puede deberse a la falta de notación de anidamiento de bloqueos [15.171834] [15.171834] 5 bloqueos retenidos por kworker/u8:3/146: [15.171834] #0: ffff888100050938 ((wq_completion)events_unbound){+.+.}-{0:0}, en: process_one_work+0x1c3/0x5a0 [15.171834] #1: ffffc9000067be80 ((work_completion)(&fs_info->async_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0 [15.176244] #2: ffff88810521e620 (sb_internal){.+.+}-{0:0}, at: flush_space+0x335/0x600 [btrfs] [15.176244] #3: ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs] [15.176244] #4: ffff8881152e4b78 (btrfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs] [15.179641] [15.179641] stack backtrace: [15.179641] CPU: 1 PID: 146 Comm: kworker/u8:3 Not tainted 5.17.0-rc6-dennis #79 [15.179641] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 01/04/2014 [15.179641] Cola de trabajo: events_unbound btrfs_async_reclaim_data_space [btrfs] [15.179641] Rastreo de llamadas: [15.179641] [15.179641] dump_stack_lvl+0x45/0x59 [15.179641] __lock_acquire.cold+0x217/0x2b2 [15.179641] lock_acquire+0xbf/0x2b0 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] __mutex_lock+0x8e/0x970 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? lock_is_held_type+0xd7/0x130 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? _raw_spin_unlock+0x24/0x40 [15.183838] ? btrfs_get_alloc_profile+0x106/0x230 [btrfs] [15.187601] btrfs_reserve_extent+0x131/0x260 [btrfs] [15. ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/mempolicy: arregla la fuga de mpol_new en shared_policy_replace Si mpol_new se asigna pero no se usa en el bucle de reinicio, mpol_new se liberará a través de mpol_put antes de regresar al llamador. Pero refcnt aún no se ha inicializado, por lo que mpol_put no podría hacer las cosas correctas y podría filtrar el mpol_new no utilizado. Esto sucedería si mempolicy se actualizara en el archivo shmem compartido mientras se eliminaba sp->lock durante la asignación de memoria. Este problema se podría activar fácilmente con el siguiente fragmento de código si hay muchos procesos haciendo el siguiente trabajo al mismo tiempo: shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); repetir muchas veces { mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); }

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: highmem: se corrigen las comprobaciones en __kmap_local_sched_{in,out}. Cuando CONFIG_DEBUG_KMAP_LOCAL está habilitado, __kmap_local_sched_{in,out} comprueba que ni siquiera las ranuras en tsk->kmap_ctrl.pteval estén asignadas. Las ranuras se inicializan con el valor 0, pero la comprobación se realiza con pte_none. Sin embargo, 0 pte no significa necesariamente que pte_none devuelva verdadero. p. ej. en xtensa devuelve falso, lo que genera las siguientes advertencias de tiempo de ejecución: ADVERTENCIA: CPU: 0 PID: 101 en mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108 CPU: 0 PID: 101 Comm: touch No contaminado 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Seguimiento de llamadas: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_out+0x51/0x108 __schedule+0x71a/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f ADVERTENCIA: CPU: 0 PID: 101 en mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0 CPU: 0 PID: 101 Comm: toque Contaminado: GW 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Seguimiento de llamadas: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_in+0x50/0xe0 Soluciónelo reemplazando !pte_none(pteval) con pte_val(pteval) != 0.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpt3sas: Se corrige el use-after-free en _scsih_expander_node_remove() La función mpt3sas_transport_port_remove() llamada en _scsih_expander_node_remove() libera el campo de puerto de la estructura sas_expander, lo que lleva al siguiente splat de use-after-free de KASAN cuando se ejecuta la llamada ioc_info() después de esa función (por ejemplo, al realizar rmmod del módulo del controlador): [ 3479.371167] ===================================================================== [ 3479.378496] ERROR: KASAN: use-after-free en _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.386936] Lectura de tamaño 1 en la dirección ffff8881c037691c por la tarea rmmod/1531 [ 3479.393524] [ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod No contaminado 5.17.0-rc8+ #1436 [ 3479.401712] Nombre del hardware: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021 [ 3479.409263] Call Trace: [ 3479.411743] [ 3479.413875] dump_stack_lvl+0x45/0x59 [ 3479.417582] print_address_description.constprop.0+0x1f/0x120 [ 3479.423389] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.429469] kasan_report.cold+0x83/0xdf [ 3479.433438] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.439514] _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.445411] ? _raw_spin_unlock_irqrestore+0x2d/0x40 [ 3479.452032] scsih_remove+0x525/0xc90 [mpt3sas] [ 3479.458212] ? mpt3sas_expander_remove+0x1d0/0x1d0 [mpt3sas] [ 3479.465529] ? down_write+0xde/0x150 [ 3479.470746] ? up_write+0x14d/0x460 [ 3479.475840] ? kernfs_find_ns+0x137/0x310 [ 3479.481438] pci_device_remove+0x65/0x110 [ 3479.487013] __device_release_driver+0x316/0x680 [ 3479.493180] driver_detach+0x1ec/0x2d0 [ 3479.498499] bus_remove_driver+0xe7/0x2d0 [ 3479.504081] pci_unregister_driver+0x26/0x250 [ 3479.510033] _mpt3sas_exit+0x2b/0x6cf [mpt3sas] [ 3479.516144] __x64_sys_delete_module+0x2fd/0x510 [ 3479.522315] ? free_module+0xaa0/0xaa0 [ 3479.527593] ? __cond_resched+0x1c/0x90 [ 3479.532951] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 3479.539607] ? syscall_enter_from_user_mode+0x21/0x70 [ 3479.546161] ? trace_hardirqs_on+0x1c/0x110 [ 3479.551828] do_syscall_64+0x35/0x80 [ 3479.556884] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 3479.563402] RIP: 0033:0x7f1fc482483b ... [ 3479.943087] ======================================================================== Solucione esto introduciendo la variable local port_id para almacenar el valor del ID del puerto antes de ejecutar mpt3sas_transport_port_remove(). Luego, esta variable local se utiliza en la llamada a ioc_info() en lugar de desreferenciar la estructura del puerto liberado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/omap: Se corrige la regresión en la sonda para la desreferencia de puntero NULL. el commit 3f6634d997db ("iommu: Use la forma correcta de recuperar iommu_ops") comenzó a activar una desreferencia de puntero NULL para algunas variantes de omap: __iommu_probe_device de probe_iommu_group+0x2c/0x38 probe_iommu_group de bus_for_each_dev+0x74/0xbc bus_for_each_dev de bus_iommu_probe+0x34/0x2e8 bus_iommu_probe de bus_set_iommu+0x80/0xc8 bus_set_iommu de omap_iommu_init+0x88/0xcc omap_iommu_init de do_one_initcall+0x44/0x24 Esto se debe a que la sonda omap iommu devuelve 0 en lugar de ERR_PTR(-ENODEV), como lo señaló Jason Gunthorpe . Parece que la regresión ya ocurrió con una confirmación anterior 6785eb9105e3 ("iommu/omap: Convertir a devoluciones de llamada de probe/release_device()") que cambió el tipo de retorno de la función y no realizó la conversión en un lugar.