Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/niu: Niu requiere que los campos ENTRY_DATA de MSIX se toquen antes de leer la entrada. Corrija niu_try_msix() para que no cause una trampa fatal en sistemas sparc. Establezca PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST en la estructura pci_dev para solucionar un error en el hardware o firmware. Para cada entrada de vector en la tabla msix, los chips niu causarán una trampa fatal si se lee algún registro en esa entrada antes de que se escriba en el registro ENTRY_DATA de esa entrada. Las pruebas indican que las escrituras en otros registros no son suficientes para evitar la trampa fatal; sin embargo, el valor no parece importar. Esto solo necesita suceder una vez después del encendido, por lo que simplemente reiniciar en un kernel que no tenga esta corrección NO causará la trampa. ERROR NO REANUDABLE: Informe de CPU 64 ERROR NO REANUDABLE: TPC [0x00000000005f6900] ERROR NO REANUDABLE: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff ERROR NO REANUDABLE: 0000000800000000:00000000000000000:00000000000000000:00000000000000000] ERROR NO REANUDABLE: handle [0x4010000000000016] stick [0x00000e37f93e32ff] ERROR NO REANUDABLE: tipo [precise nonresumable] ERROR NO REANUDABLE: attrs [0x02000080] < ASI sp-faulted priv > ERROR NO REANUDABLE: raddr [0xffffffffffffffff] ERROR NO REANUDABLE: dirección efectiva insn [0x000000c50020000c] ERROR NO REANUDABLE: tamaño [0x8] ERROR NO REANUDABLE: asi [0x00] CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 No contaminado 6.11.5 #63 Cola de trabajo: eventos work_for_cpu_fn TSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 No contaminado TPC: g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100 g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000 o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620 o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128 RPC: <__pci_enable_msix_range+0x3cc/0x460> l0: 00000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020 l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734 i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d i4: 000000000000000000000000000000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0 I7: Rastreo de llamadas: [<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu] [<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu] [<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu] [<00000000005ef3e4>] local_pci_probe+0x28/0x74 [<0000000000469240>] work_for_cpu_fn+0x8/0x1c [<000000000046b008>] process_scheduled_works+0x144/0x210 [<000000000046b518>] workers_thread+0x13c/0x1c0 [<00000000004710e0>] kthread+0xb8/0xc8 [<00000000004060c8>] ret_from_fork+0x1c/0x2c [<0000000000000000>] 0x0 Pánico del kernel: no se sincroniza: Error no reanudable.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vmscan: no intente reclamar el folio hwpoison Syzkaller informa un error de la siguiente manera: Error de inyección de memoria para pfn 0x18b00e en la dirección virtual del proceso 0x20ffd000 Error de memoria: 0x18b00e: 2 usuarios aún hacen referencia a la página de swapcache sucia Error de memoria: 0x18b00e: acción de recuperación para la página de swapcache sucia: Página con errores: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(bloqueado|sucio|arch_1|swapbacked|hwpoison|nodo=0|zona=2|lastcpupid=0xfffff) sin procesar: 005ffffe00482011 muerto000000000100 muerto000000000122 ffff0000e232a7c9 sin procesar: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 página volcada porque: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cortar aquí ]------------ ¡ERROR del kernel en mm/swap_state.c:184! Error interno: Ups - BUG: 00000000f2000800 [#1] Módulos SMP vinculados: CPU: 0 PID: 60 Comm: kswapd0 No contaminado 6.6.0-gcb097e7de84e #3 Nombre del hardware: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : add_to_swap+0xbc/0x158 lr : add_to_swap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9: dfff800000000000 x8: 00009fffc9274686 x7: ffff0001b6c5cbd3 x6: 000000000000001 x5: ffff0000c25896c0 x4: 0000000000000000 x3: 00000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Rastreo de llamadas: add_to_swap+0xbc/0x158 shrink_folio_list+0x12ac/0x2648 shrink_inactive_list+0x318/0x948 shrink_lruvec+0x450/0x720 shrink_node_memcgs+0x280/0x4a8 shrink_node+0x128/0x978 balance_pgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214/0x230 ret_from_fork+0x10/0x20 Puedo reproducir este problema con los siguientes pasos: 1) Cuando una página de caché de intercambio sucia es aislada por el proceso de recuperación y la página no está bloqueada, se inyecta un fallo de memoria para la página. me_swapcache_dirty() borra el indicador de actualización e intenta eliminarla de la unidad de recuperación (LRU), pero falla. El proceso de recuperación devolverá la página contaminada a la LRU. 2) El proceso que asigna la página contaminada sale, la página se elimina, la página nunca se liberará y permanecerá en la LRU para siempre. 3) Si activamos una recuperación de nuevo e intentamos recuperar la página, add_to_swap() activará VM_BUG_ON_FOLIO debido a que el indicador de actualización está borrado. Para solucionarlo, omita la página contaminada en la lista de recuperación (shrink_folio_list()). Además, es posible que el folio hwpoison aún no esté desasignado por hwpoison_user_mappings(), desasignelo en shrink_folio_list(), de lo contrario el folio no podrá ser desasignado por hwpoison_user_mappings() ya que el folio no está en la lista lru.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: scmi: Se corrige la corrección de null-ptr-deref en scmi_cpufreq_get_rate(). cpufreq_cpu_get_raw() puede devolver NULL cuando la CPU de destino no está presente en la máscara policy->cpus. scmi_cpufreq_get_rate() no comprueba este caso, lo que resulta en una desreferencia de puntero NULL. Añadir la comprobación de NULL después de cpufreq_cpu_get_raw() para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: se corrige el acceso fuera de los límites en nvmet_enable_port Al intentar habilitar un puerto que aún no tiene transporte configurado, nvmet_enable_port() usa NVMF_TRTYPE_MAX (255) para consultar la matriz de transportes, lo que provoca un acceso fuera de los límites: [ 106.058694] ERROR: KASAN: global fuera de los límites en nvmet_enable_port+0x42/0x1da [ 106.058719] Lectura de tamaño 8 en la dirección ffffffff89dafa58 por la tarea ln/632 [...] [ 106.076026] nvmet: no se admite el tipo de transporte 255 Desde la confirmación 200adac75888, NVMF_TRTYPE_MAX es el estado predeterminado según la configuración de nvmet_ports_make(). Evite esto verificando NVMF_TRTYPE_MAX antes de continuar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: corrige la desreferencia del puntero NULL en tipc_mon_reinit_self() syzbot informó: tipc: Número de nodo establecido en 1055423674 Oops: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 No contaminado 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full) Nombre del hardware: QEMU PC estándar (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 Cola de trabajo: eventos tipc_net_finalize_work RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [en línea] subproceso_de_trabajo+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_de_bifurcación+0x45/0x80 arch/x86/kernel/process.c:153 ret_de_bifurcación_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ... RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 00000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Hay una condición de ejecución entre la cola de trabajo creada al habilitar el portador y otro hilo creado al deshabilitar el portador justo después de eso, como se muestra a continuación: enabling_bearer | disabling_bearer --------------- | ---------------- tipc_disc_timeout() | { | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | { } | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | } tipc_net_finalize_work() | } { | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: hfsc: Se corrige también un posible UAF en hfsc_dequeue(). Al igual que en el parche anterior, también debemos proteger hfsc_dequeue(). Sin embargo, para este caso, no contamos con un reproductor fiable.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: return EIO on RAID1 block group write pointer mismatch Hubo un informe de error sobre una desreferencia de puntero NULL en __btrfs_add_free_space_zoned() que en última instancia ocurre debido a una conversión del perfil de metadatos predeterminado DUP a un perfil RAID1 en dos discos. El seguimiento de la pila tiene la siguiente firma: Error BTRFS (dispositivo sdc): zoned: desajuste del desplazamiento del puntero de escritura de las zonas en el perfil raid1 ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000058 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 RSP: 0018:ffffa236b6f3f6d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff96c8132f3400 RCX: 0000000000000001 RDX: 0000000010000000 RSI: 0000000000000000 RDI: ffff96c8132f3410 RBP: 0000000010000000 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000 R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000 FS: 00007fdab1cb2900(0000) GS:ffff96e60ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 00000001a05ae000 CR4: 0000000000350ef0 Seguimiento de llamadas: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15c/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 btrfs_add_free_space_async_trimmed+0x34/0x40 btrfs_add_new_free_space+0x107/0x120 btrfs_make_block_group+0x104/0x2b0 btrfs_create_chunk+0x977/0xf20 btrfs_chunk_alloc+0x174/0x510 ? srso_return_thunk+0x5/0x5f btrfs_inc_block_group_ro+0x1b1/0x230 btrfs_relocate_block_group+0x9e/0x410 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x8ac/0x12b0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? __kmalloc_cache_noprof+0x14c/0x3e0 btrfs_ioctl+0x2686/0x2a80 ? srso_return_thunk+0x5/0x5f ? ioctl_has_perm.constprop.0.isra.0+0xd2/0x120 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x82/0x160 ? srso_return_thunk+0x5/0x5f ? __memcg_slab_free_hook+0x11a/0x170 ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x3f0/0x450 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? sysfs_emit+0xaf/0xc0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? seq_read_iter+0x207/0x460 ? srso_return_thunk+0x5/0x5f ? vfs_read+0x29c/0x370 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? srso_return_thunk+0x5/0x5f ? exc_page_fault+0x7e/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdab1e0ca6d RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdab1e0ca6d RDX: 00007ffeb2b60d80 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 00007ffeb2b60cd0 R08: 0000000000000000 R09: 0000000000000013 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffeb2b6343b R14: 00007ffeb2b60d80 R15: 0000000000000001 CR2: 0000000000000058 ---[ fin del seguimiento 000000000000000 ]--- La primera línea es la más interesante aquí: Error BTRFS (dispositivo sdc): zoned: discrepancia en el desplazamiento del puntero de escritura de las zonas en el perfil RAID1. Cuando se crea un grupo de bloques RAID1 y se detecta una discrepancia en el desplazamiento del puntero de escritura entre los discos del conjunto RAID, btrfs establece el valor de alloc_offset en la longitud del grupo de bloques, marcándolo como lleno. Posteriormente, el código espera que una operación de balance evacue los datos de este grupo de bloques y solucione los problemas. Sin embargo, antes de que esto sea posible, el nuevo espacio de este grupo de bloques se contabilizará en la caché de espacio libre. ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/eevdf: Se soluciona que se->slice se establezca en U64_MAX y el bloqueo resultante Hay una ruta de código en dequeue_entities() que puede establecer el slice de un sched_entity en U64_MAX, lo que a veces resulta en un bloqueo. El caso ofensivo es cuando se llama a dequeue_entities() para sacar de la cola una entidad de grupo retrasada y luego se retrasa la salida de la cola del padre de la entidad. En ese caso: 1. En el bloque if (entity_is_task(se)) else al comienzo de dequeue_entities(), slice se establece en cfs_rq_min_slice(group_cfs_rq(se)). Si la entidad se retrasó, entonces no tiene tareas en cola, por lo que cfs_rq_min_slice() devuelve U64_MAX. 2. El primer bucle for_each_sched_entity() saca de la cola la entidad. 3. Si la entidad era la única hija de su padre, la siguiente iteración intenta sacar de la cola al padre. 4. Si es necesario retrasar la salida de la cola del padre, se interrumpe desde el primer bucle for_each_sched_entity() _sin actualizar la porción_. 5. El segundo bucle for_each_sched_entity() establece la porción -> del padre en la porción guardada, que sigue siendo U64_MAX. Esto altera los cálculos posteriores con resultados potencialmente catastróficos. Una manifestación que vimos en producción fue: 6. En update_entity_lag(), se->slice se usa para calcular el límite, que termina como un número negativo enorme. 7. limit se usa en se->vlag = clamp(vlag, -limit, limit). Como limit es negativo, vlag > limit, por lo que se->vlag se establece en el mismo número negativo enorme. 8. En place_entity(), se->vlag se escala, lo que se desborda y da como resultado otro número enorme (positivo o negativo). 9. El retardo ajustado se resta de se->vruntime, lo que aumenta o disminuye se->vruntime considerablemente. 10. pick_eevdf() llama a entity_eligible()/vruntime_eligible(), que devuelve incorrectamente "false" debido a la gran distancia entre el vruntime y los demás vruntimes de la cola, lo que provoca un desbordamiento del cálculo de carga (vruntime - cfs_rq->min_vruntime) *. 11. Nada parece ser elegible, por lo que pick_eevdf() devuelve NULL. 12. pick_next_entity() intenta desreferenciar el valor de retorno de pick_eevdf() y se bloquea. Volcar los estados de cfs_rq desde los volcados de núcleo con drgn mostró rangos de tiempo de ejecución virtuales enormes y valores de vlag falsos, y también rastreé que se->slice se configuraba en U64_MAX en sistemas en vivo (lo cual solía ser "benigno", ya que el resto de la cola de ejecución debía estar en un estado específico para fallar). Corríjalo en dequeue_entities() configurando siempre slice desde el primer cfs_rq no vacío.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen-netfront: manejador NULL devuelto por xdp_convert_buff_to_frame(). La función xdp_convert_buff_to_frame() puede devolver NULL si no convierte correctamente el búfer XDP en un marco XDP debido a limitaciones de memoria, errores internos o datos no válidos. No comprobar si hay NULL puede provocar una desreferencia de puntero NULL si el resultado se utiliza más adelante en el procesamiento, lo que puede causar fallos, corrupción de datos o un comportamiento indefinido. En caso de fallo en la redirección XDP, la página asociada debe liberarse explícitamente si se retuvo previamente mediante get_page(). No hacerlo puede provocar una fuga de memoria, ya que el recuento de referencias de páginas no se reduce.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/gic-v2m: Impedir el uso tras la liberación de gicv2m_get_fwnode() Con ACPI en su lugar, gicv2m_get_fwnode() se registra en el subsistema pci como pci_msi_get_fwnode_cb(), que puede invocarse en tiempo de ejecución durante un sondeo de puente de host PCI. Pero, la devolución de llamada se marca erróneamente como __init, lo que provoca que se libere, mientras se registra en el subsistema PCI y podría desencadenar: No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548 Esto es fácilmente reproducible en una placa Juno con arranque ACPI. Conserve la función para uso posterior.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Devuelve NULL desde huge_pte_offset() para PMD no válido. La función huge_pte_offset() de LoongArch actualmente devuelve un puntero a una ranura PMD incluso si la entrada subyacente apunta a invalid_pte_table (lo que indica que no hay asignación). Llamadores como smaps_hugetlb_range() obtienen este valor de entrada no válido (la dirección de invalid_pte_table) a través de este puntero. La comprobación genérica is_swap_pte() identifica incorrectamente esta dirección como una entrada de intercambio en LoongArch, ya que cumple las condiciones "!pte_present() && !pte_none()". Esta interpretación errónea, combinada con una coincidencia de is_migration_entry() en los bits de dirección, provoca fallos del kernel en pfn_swap_entry_to_page(). Solucione esto a nivel de arquitectura modificando huge_pte_offset() para comprobar el contenido de la entrada PMD mediante pmd_none() antes de regresar. Si la entrada no es válida (es decir, apunta a invalid_pte_table), devuelva NULL en lugar del puntero a la ranura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Añadir comprobación de valores nulos en ufshcd_mcq_compl_pending_transfer(). Añadir una comprobación de valores nulos para el puntero hwq devuelto por ufshcd_mcq_req_to_hwq(). Esto es similar a la corrección en el commit 74736103fb41 ("scsi: ufs: core: Corregir el problema de ejecuciones de ufshcd_abort_one").