Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: release path before inode lookup during the ino lookup ioctl<br /> <br /> During the ino lookup ioctl we can end up calling btrfs_iget() to get an<br /> inode reference while we are holding on a root&amp;#39;s btree. If btrfs_iget()<br /> needs to lookup the inode from the root&amp;#39;s btree, because it&amp;#39;s not<br /> currently loaded in memory, then it will need to lock another or the<br /> same path in the same root btree. This may result in a deadlock and<br /> trigger the following lockdep splat:<br /> <br /> WARNING: possible circular locking dependency detected<br /> 6.5.0-rc7-syzkaller-00004-gf7757129e3de #0 Not tainted<br /> ------------------------------------------------------<br /> syz-executor277/5012 is trying to acquire lock:<br /> ffff88802df41710 (btrfs-tree-01){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> <br /> but task is already holding lock:<br /> ffff88802df418e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (btrfs-tree-00){++++}-{3:3}:<br /> down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645<br /> __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> btrfs_search_slot+0x13a4/0x2f80 fs/btrfs/ctree.c:2302<br /> btrfs_init_root_free_objectid+0x148/0x320 fs/btrfs/disk-io.c:4955<br /> btrfs_init_fs_root fs/btrfs/disk-io.c:1128 [inline]<br /> btrfs_get_root_ref+0x5ae/0xae0 fs/btrfs/disk-io.c:1338<br /> btrfs_get_fs_root fs/btrfs/disk-io.c:1390 [inline]<br /> open_ctree+0x29c8/0x3030 fs/btrfs/disk-io.c:3494<br /> btrfs_fill_super+0x1c7/0x2f0 fs/btrfs/super.c:1154<br /> btrfs_mount_root+0x7e0/0x910 fs/btrfs/super.c:1519<br /> legacy_get_tree+0xef/0x190 fs/fs_context.c:611<br /> vfs_get_tree+0x8c/0x270 fs/super.c:1519<br /> fc_mount fs/namespace.c:1112 [inline]<br /> vfs_kern_mount+0xbc/0x150 fs/namespace.c:1142<br /> btrfs_mount+0x39f/0xb50 fs/btrfs/super.c:1579<br /> legacy_get_tree+0xef/0x190 fs/fs_context.c:611<br /> vfs_get_tree+0x8c/0x270 fs/super.c:1519<br /> do_new_mount+0x28f/0xae0 fs/namespace.c:3335<br /> do_mount fs/namespace.c:3675 [inline]<br /> __do_sys_mount fs/namespace.c:3884 [inline]<br /> __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> -&gt; #0 (btrfs-tree-01){++++}-{3:3}:<br /> check_prev_add kernel/locking/lockdep.c:3142 [inline]<br /> check_prevs_add kernel/locking/lockdep.c:3261 [inline]<br /> validate_chain kernel/locking/lockdep.c:3876 [inline]<br /> __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144<br /> lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761<br /> down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645<br /> __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> btrfs_tree_read_lock fs/btrfs/locking.c:142 [inline]<br /> btrfs_read_lock_root_node+0x292/0x3c0 fs/btrfs/locking.c:281<br /> btrfs_search_slot_get_root fs/btrfs/ctree.c:1832 [inline]<br /> btrfs_search_slot+0x4ff/0x2f80 fs/btrfs/ctree.c:2154<br /> btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:412<br /> btrfs_read_locked_inode fs/btrfs/inode.c:3892 [inline]<br /> btrfs_iget_path+0x2d9/0x1520 fs/btrfs/inode.c:5716<br /> btrfs_search_path_in_tree_user fs/btrfs/ioctl.c:1961 [inline]<br /> btrfs_ioctl_ino_lookup_user+0x77a/0xf50 fs/btrfs/ioctl.c:2105<br /> btrfs_ioctl+0xb0b/0xd40 fs/btrfs/ioctl.c:4683<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl+0xf8/0x170 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> other info <br /> ---truncated---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: sintonizadores: qt1010: reemplazar BUG_ON con un error regular<br /> <br /> BUG_ON es innecesario aquí, y además confunde a smatch.<br /> Reemplazar esto con un retorno de error ayuda a resolver esta advertencia de smatch:<br /> <br /> drivers/media/tuners/qt1010.c:350 qt1010_init() error: desbordamiento de búfer &amp;#39;i2c_data&amp;#39; 34 &amp;lt;= 34

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bpf: Abordar el informe de KCSAN sobre bpf_lru_list<br /> <br /> KCSAN informó una condición de carrera de datos al acceder a node-&amp;gt;ref.<br /> Aunque node-&amp;gt;ref no tiene que ser preciso,<br /> aprovechar esta oportunidad para usar un patrón más común de READ_ONCE() y WRITE_ONCE()<br /> en lugar de data_race().<br /> <br /> Existe un bpf_lru_node_is_ref() y un bpf_lru_node_set_ref().<br /> Este parche también añade bpf_lru_node_clear_ref() para hacer el<br /> WRITE_ONCE(node-&amp;gt;ref, 0) también.<br /> <br /> ==================================================================<br /> ERROR: KCSAN: condición de carrera de datos en __bpf_lru_list_rotate / __htab_lru_percpu_map_update_elem<br /> <br /> escritura en 0xffff888137038deb de 1 byte por la tarea 11240 en la CPU 1:<br /> __bpf_lru_node_move kernel/bpf/bpf_lru_list.c:113 [en línea]<br /> __bpf_lru_list_rotate_active kernel/bpf/bpf_lru_list.c:149 [en línea]<br /> __bpf_lru_list_rotate+0x1bf/0x750 kernel/bpf/bpf_lru_list.c:240<br /> bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:329 [en línea]<br /> bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [en línea]<br /> bpf_lru_pop_free+0x638/0xe20 kernel/bpf/bpf_lru_list.c:499<br /> prealloc_lru_pop kernel/bpf/hashtab.c:290 [en línea]<br /> __htab_lru_percpu_map_update_elem+0xe7/0x820 kernel/bpf/hashtab.c:1316<br /> bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313<br /> bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200<br /> generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687<br /> bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534<br /> __sys_bpf+0x338/0x810<br /> __do_sys_bpf kernel/bpf/syscall.c:5096 [en línea]<br /> __se_sys_bpf kernel/bpf/syscall.c:5094 [en línea]<br /> __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094<br /> do_syscall_x64 arch/x86/entry/common.c:50 [en línea]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> lectura en 0xffff888137038deb de 1 byte por la tarea 11241 en la CPU 0:<br /> bpf_lru_node_set_ref kernel/bpf/bpf_lru_list.h:70 [en línea]<br /> __htab_lru_percpu_map_update_elem+0x2f1/0x820 kernel/bpf/hashtab.c:1332<br /> bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313<br /> bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200<br /> generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687<br /> bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534<br /> __sys_bpf+0x338/0x810<br /> __do_sys_bpf kernel/bpf/syscall.c:5096 [en línea]<br /> __se_sys_bpf kernel/bpf/syscall.c:5094 [en línea]<br /> __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094<br /> do_syscall_x64 arch/x86/entry/common.c:50 [en línea]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> valor cambiado: 0x01 -&amp;gt; 0x00<br /> <br /> Reportado por Kernel Concurrency Sanitizer en:<br /> CPU: 0 PID: 11241 Comm: syz-executor.3 No contaminado 6.3.0-rc7-syzkaller-00136-g6a66fdd29ea1 #0<br /> Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023<br /> ==================================================================

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> tty: serial: imx: deshabilitar la solicitud de interrupción irq del temporizador de envejecimiento<br /> <br /> Puede haber una interrupción USR pendiente antes de solicitar irq, sin embargo, uart_add_one_port no se ha ejecutado, por lo que habrá un pánico del kernel:<br /> [ 0.795668] Incapaz de manejar la desreferencia de puntero NULL del kernel en la dirección virtual 0000000000000080<br /> [ 0.802701] Información de aborto de memoria:<br /> [ 0.805367] ESR = 0x0000000096000004<br /> [ 0.808950] EC = 0x25: DABT (EL actual), IL = 32 bits<br /> [ 0.814033] SET = 0, FnV = 0<br /> [ 0.816950] EA = 0, S1PTW = 0<br /> [ 0.819950] FSC = 0x04: fallo de traducción de nivel 0<br /> [ 0.824617] Información de aborto de datos:<br /> [ 0.827367] ISV = 0, ISS = 0x00000004<br /> [ 0.831033] CM = 0, WnR = 0<br /> [ 0.833866] [0000000000000080] dirección de usuario pero active_mm es swapper<br /> [ 0.839951] Error interno: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [ 0.845953] Módulos enlazados:<br /> [ 0.848869] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.1+g56321e101aca #1<br /> [ 0.855617] Nombre del hardware: Freescale i.MX8MP EVK (DT)<br /> [ 0.860452] pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 0.867117] pc : __imx_uart_rxint.constprop.0+0x11c/0x2c0<br /> [ 0.872283] lr : imx_uart_int+0xf8/0x1ec<br /> <br /> El problema solo ocurre en el linux &amp;#39;inmate&amp;#39; cuando el hipervisor Jailhouse está habilitado. El procedimiento de prueba es:<br /> while true; do<br /> jailhouse enable imx8mp.cell<br /> jailhouse cell linux xxxx<br /> sleep 10<br /> jailhouse cell destroy 1<br /> jailhouse disable<br /> sleep 5<br /> done<br /> <br /> Y durante la prueba anterior, presione teclas en la segunda consola de linux.<br /> Cuando &amp;#39;jailhouse cell destroy 1&amp;#39;, el segundo linux no tiene oportunidad de poner el uart en un estado de reposo, por lo que USR1/2 puede tener interrupciones pendientes. Luego, cuando &amp;#39;jailhosue cell linux xx&amp;#39; para iniciar el segundo linux nuevamente, el problema se activa.<br /> <br /> Para deshabilitar las irqs antes de solicitarlas, tanto las irqs de UCR1 como las de UCR2 deben deshabilitarse, así que aquí se corrige eso, deshabilitando la interrupción del temporizador de envejecimiento en UCR2 como lo hace UCR1.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fortify the spinlock against deadlock by interrupt<br /> <br /> In the function ieee80211_tx_dequeue() there is a particular locking<br /> sequence:<br /> <br /> begin:<br /> spin_lock(&amp;local-&gt;queue_stop_reason_lock);<br /> q_stopped = local-&gt;queue_stop_reasons[q];<br /> spin_unlock(&amp;local-&gt;queue_stop_reason_lock);<br /> <br /> However small the chance (increased by ftracetest), an asynchronous<br /> interrupt can occur in between of spin_lock() and spin_unlock(),<br /> and the interrupt routine will attempt to lock the same<br /> &amp;local-&gt;queue_stop_reason_lock again.<br /> <br /> This will cause a costly reset of the CPU and the wifi device or an<br /> altogether hang in the single CPU and single core scenario.<br /> <br /> The only remaining spin_lock(&amp;local-&gt;queue_stop_reason_lock) that<br /> did not disable interrupts was patched, which should prevent any<br /> deadlocks on the same CPU/core and the same wifi device.<br /> <br /> This is the probable trace of the deadlock:<br /> <br /> kernel: ================================<br /> kernel: WARNING: inconsistent lock state<br /> kernel: 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4 Tainted: G W<br /> kernel: --------------------------------<br /> kernel: inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage.<br /> kernel: kworker/5:0/25656 [HC0[0]:SC0[0]:HE1:SE1] takes:<br /> kernel: ffff9d6190779478 (&amp;local-&gt;queue_stop_reason_lock){+.?.}-{2:2}, at: return_to_handler+0x0/0x40<br /> kernel: {IN-SOFTIRQ-W} state was registered at:<br /> kernel: lock_acquire+0xc7/0x2d0<br /> kernel: _raw_spin_lock+0x36/0x50<br /> kernel: ieee80211_tx_dequeue+0xb4/0x1330 [mac80211]<br /> kernel: iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm]<br /> kernel: iwl_mvm_mac_wake_tx_queue+0x2d/0xd0 [iwlmvm]<br /> kernel: ieee80211_queue_skb+0x450/0x730 [mac80211]<br /> kernel: __ieee80211_xmit_fast.constprop.66+0x834/0xa50 [mac80211]<br /> kernel: __ieee80211_subif_start_xmit+0x217/0x530 [mac80211]<br /> kernel: ieee80211_subif_start_xmit+0x60/0x580 [mac80211]<br /> kernel: dev_hard_start_xmit+0xb5/0x260<br /> kernel: __dev_queue_xmit+0xdbe/0x1200<br /> kernel: neigh_resolve_output+0x166/0x260<br /> kernel: ip_finish_output2+0x216/0xb80<br /> kernel: __ip_finish_output+0x2a4/0x4d0<br /> kernel: ip_finish_output+0x2d/0xd0<br /> kernel: ip_output+0x82/0x2b0<br /> kernel: ip_local_out+0xec/0x110<br /> kernel: igmpv3_sendpack+0x5c/0x90<br /> kernel: igmp_ifc_timer_expire+0x26e/0x4e0<br /> kernel: call_timer_fn+0xa5/0x230<br /> kernel: run_timer_softirq+0x27f/0x550<br /> kernel: __do_softirq+0xb4/0x3a4<br /> kernel: irq_exit_rcu+0x9b/0xc0<br /> kernel: sysvec_apic_timer_interrupt+0x80/0xa0<br /> kernel: asm_sysvec_apic_timer_interrupt+0x1f/0x30<br /> kernel: _raw_spin_unlock_irqrestore+0x3f/0x70<br /> kernel: free_to_partial_list+0x3d6/0x590<br /> kernel: __slab_free+0x1b7/0x310<br /> kernel: kmem_cache_free+0x52d/0x550<br /> kernel: putname+0x5d/0x70<br /> kernel: do_sys_openat2+0x1d7/0x310<br /> kernel: do_sys_open+0x51/0x80<br /> kernel: __x64_sys_openat+0x24/0x30<br /> kernel: do_syscall_64+0x5c/0x90<br /> kernel: entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> kernel: irq event stamp: 5120729<br /> kernel: hardirqs last enabled at (5120729): [] trace_graph_return+0xd6/0x120<br /> kernel: hardirqs last disabled at (5120728): [] trace_graph_return+0xf0/0x120<br /> kernel: softirqs last enabled at (5069900): [] return_to_handler+0x0/0x40<br /> kernel: softirqs last disabled at (5067555): [] return_to_handler+0x0/0x40<br /> kernel:<br /> other info that might help us debug this:<br /> kernel: Possible unsafe locking scenario:<br /> kernel: CPU0<br /> kernel: ----<br /> kernel: lock(&amp;local-&gt;queue_stop_reason_lock);<br /> kernel: <br /> kernel: lock(&amp;local-&gt;queue_stop_reason_lock);<br /> kernel:<br /> *** DEADLOCK ***<br /> kernel: 8 locks held by kworker/5:0/25656:<br /> kernel: #0: ffff9d618009d138 ((wq_completion)events_freezable){+.+.}-{0:0}, at: process_one_work+0x1ca/0x530<br /> kernel: #1: ffffb1ef4637fe68 ((work_completion)(&amp;local-&gt;restart_work)){+.+.}-{0:0}, at: process_one_work+0x1ce/0x530<br /> kernel: #2: ffffffff9f166548 (rtnl_mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40<br /> kernel: #3: ffff9d619<br /> ---truncated---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: qedf: Solución a la desreferencia de NULL en el manejo de errores<br /> <br /> Smatch informó:<br /> <br /> drivers/scsi/qedf/qedf_main.c:3056 qedf_alloc_global_queues()<br /> advertencia: ¿falta un goto de desenrollado?<br /> <br /> En este punto de la función, nada ha sido asignado por lo que podemos retornar directamente. En particular, los &amp;#39;qedf-&amp;gt;global_queues&amp;#39; no han sido asignados, por lo que llamar a qedf_free_global_queues() conducirá a una desreferencia de NULL cuando comprobemos si (!gl[i]) y &amp;#39;gl&amp;#39; es NULL.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: av7110: evitar desbordamiento negativo en write_ts_to_decoder()<br /> <br /> El valor de buf[4] proviene del usuario a través de ts_play(). Es un valor en el rango u8. La longitud final que pasamos a av7110_ipack_instant_repack() es &amp;#39;len - (buf[4] + 1) - 4&amp;#39;, por lo que se añade una comprobación para asegurar que la longitud no sea negativa. No está claro que pasar un valor &amp;#39;len&amp;#39; negativo cause algo malo necesariamente, pero no es una buena práctica.<br /> <br /> Con la nueva comprobación de límites, la condición &amp;#39;if (!len)&amp;#39; ya no es posible ni necesaria, por lo que se elimina.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iomap: Corrige una posible condición de desbordamiento en iomap_write_delalloc_scan<br /> <br /> folio_next_index() devuelve un valor unsigned long que, desplazado a la izquierda por PAGE_SHIFT, podría causar un desbordamiento en sistemas de 32 bits. En su lugar, usa folio_pos(folio) + folio_size(folio), lo cual lo hace correctamente.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: iwlwifi: dvm: Corrección de memcpy: se detectó un rastreo de pila de escritura que abarca campos<br /> <br /> Una clave TKIP recibida puede tener hasta 32 bytes porque también puede contener claves MIC rx/tx. Estas no son utilizadas por iwl y copiarlas desborda el campo iwl_keyinfo.key.<br /> <br /> Añadir una comprobación para no copiar más datos a iwl_keyinfo.key de los que caben.<br /> <br /> Esto corrige rastreos de pila como este:<br /> <br /> memcpy: se detectó una escritura que abarca campos (tamaño 32) de un solo campo &amp;#39;sta_cmd.key.key&amp;#39; en drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 (tamaño 16)<br /> ADVERTENCIA: CPU: 1 PID: 946 en drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 iwlagn_send_sta_key+0x375/0x390 [iwldvm]<br /> <br /> Nombre del hardware: Dell Inc. Latitude E6430/0H3MT5, BIOS A21 05/08/2017<br /> RIP: 0010:iwlagn_send_sta_key+0x375/0x390 [iwldvm]<br /> <br /> Rastreo de Llamadas:<br /> <br /> iwl_set_dynamic_key+0x1f0/0x220 [iwldvm]<br /> iwlagn_mac_set_key+0x1e4/0x280 [iwldvm]<br /> drv_set_key+0xa4/0x1b0 [mac80211]<br /> ieee80211_key_enable_hw_accel+0xa8/0x2d0 [mac80211]<br /> ieee80211_key_replace+0x22d/0x8e0 [mac80211]<br />

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fs/ntfs3: Corregir una posible desreferencia de puntero nulo en ni_clear()<br /> <br /> En un commit anterior c1006bd13146, ni-&amp;gt;mi.mrec en ni_write_inode() podría ser NULL, y por lo tanto se añade una comprobación de NULL para esta variable.<br /> <br /> Sin embargo, en la misma pila de llamadas, ni-&amp;gt;mi.mrec también puede ser desreferenciado en ni_clear():<br /> <br /> ntfs_evict_inode(inode)<br /> ni_write_inode(inode, ...)<br /> ni = ntfs_i(inode);<br /> is_rec_inuse(ni-&amp;gt;mi.mrec) -&amp;gt; Se añade una comprobación de NULL por el commit anterior<br /> ni_clear(ntfs_i(inode))<br /> is_rec_inuse(ni-&amp;gt;mi.mrec) -&amp;gt; Sin comprobación<br /> <br /> Por lo tanto, una posible desreferencia de puntero nulo puede existir en ni_clear().<br /> Para corregirlo, se añade una comprobación de NULL en esta función.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> xfrm: Corrección de fuga de rastreador de dispositivo<br /> <br /> En la etapa de las comprobaciones de dirección, el rastreador de referencias netdev ya está inicializado, pero liberado con una llamada *_put() incorrecta.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> RDMA/srpt: Añadir una comprobación para un puntero &amp;#39;mad_agent&amp;#39; válido<br /> <br /> Al anular el registro del agente MAD, el módulo srpt tiene una comprobación de no nulidad para el puntero &amp;#39;mad_agent&amp;#39; antes de invocar ib_unregister_mad_agent().<br /> Esta comprobación puede pasar si la variable &amp;#39;mad_agent&amp;#39; contiene un valor de error.<br /> El &amp;#39;mad_agent&amp;#39; puede tener un valor de error durante una ventana corta cuando srpt_add_one() y srpt_remove_one() se ejecutan simultáneamente.<br /> <br /> En el módulo srpt, se añadió una comprobación de puntero válido para &amp;#39;sport-&amp;gt;mad_agent&amp;#39; antes de anular el registro del agente MAD.<br /> <br /> Este problema puede ocurrir cuando el controlador RoCE anula el registro de ib_device<br /> <br /> Traza de la pila:<br /> ------------<br /> BUG: desreferencia de puntero NULL del kernel, dirección: 000000000000004d<br /> PGD 145003067 P4D 145003067 PUD 2324fe067 PMD 0<br /> Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> CPU: 10 PID: 4459 Comm: kworker/u80:0 Kdump: loaded Tainted: P<br /> Nombre del hardware: Dell Inc. PowerEdge R640/06NR82, BIOS 2.5.4 01/13/2020<br /> Cola de trabajo: bnxt_re bnxt_re_task [bnxt_re]<br /> RIP: 0010:_raw_spin_lock_irqsave+0x19/0x40<br /> Traza de llamada:<br /> ib_unregister_mad_agent+0x46/0x2f0 [ib_core]<br /> IPv6: ADDRCONF(NETDEV_CHANGE): bond0: el enlace está listo<br /> ? __schedule+0x20b/0x560<br /> srpt_unregister_mad_agent+0x93/0xd0 [ib_srpt]<br /> srpt_remove_one+0x20/0x150 [ib_srpt]<br /> remove_client_context+0x88/0xd0 [ib_core]<br /> bond0: (esclavo p2p1): estado del enlace definitivamente activo, 100000 Mbps full duplex<br /> disable_device+0x8a/0x160 [ib_core]<br /> bond0: ¡interfaz activa levantada!<br /> ? kernfs_name_hash+0x12/0x80<br /> (dispositivo NULL *): Información de Bonding Recibida: rdev: 000000006c0b8247<br /> __ib_unregister_device+0x42/0xb0 [ib_core]<br /> (dispositivo NULL *): Maestro: modo: 4 num_slaves:2<br /> ib_unregister_device+0x22/0x30 [ib_core]<br /> (dispositivo NULL *): Esclavo: id: 105069936 nombre:p2p1 enlace:0 estado:0<br /> bnxt_re_stopqps_and_ib_uninit+0x83/0x90 [bnxt_re]<br /> bnxt_re_alloc_lag+0x12e/0x4e0 [bnxt_re]