Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: qcom: at803x: corrige el pánico del kernel con at8031_probe Al reelaborar y dividir el controlador at803x, en la función de división de los PHY de at803x se agregó un error de desreferencia NULL donde se hace referencia a priv antes de que realmente se asigne y luego se intenta escribir para las variables is_1000basex e is_fiber en el caso de at8031, escribiendo en la dirección incorrecta. Solucione este problema configurando correctamente la variable local priv solo después de llamar a at803x_probe y realmente asignar priv en la estructura phydev.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nouveau/dmem: maneja el error de asignación de kcalloc() El kcalloc() en nouveau_dmem_evict_chunk() devolverá nulo si la memoria física se ha agotado. Como resultado, si eliminamos la referencia a src_pfns, dst_pfns o dma_addrs, se producirán errores de desreferenciación del puntero nulo. Además, la GPU está desapareciendo. Si kcalloc() falla, no podremos desalojar todas las páginas que asignan un fragmento. Entonces este parche agrega un indicador __GFP_NOFAIL en kcalloc(). Finalmente, como no es necesario tener memoria físicamente contigua, este parche cambia kcalloc() a kvcalloc() para evitar asignaciones fallidas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/i915/vma: Corrección de UAF al destruir contra ejecución de retirada. Las herramientas de depuración de objetos informaban esporádicamente intentos ilegales de liberar un objeto i915 VMA aún activo al estacionar un GT que se creía que estaba inactivo. [161.359441] ODEBUG: objeto activo libre (estado activo 0): ffff88811643b958 tipo de objeto: i915_active sugerencia: __i915_vma_active+0x0/0x50 [i915] [161.360082] ADVERTENCIA: CPU: 5 PID: 276 en lib/debugobjects.c:514 _imprimir_objeto+ 0x80/0xb0 ... [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 No contaminado 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1 [161.360314] Nombre de hardware: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 21/04/2022 [161.360322] Cola de trabajo: i915 desordenado __intel_wakeref_put_work [i915] [161.360592] RIP 0010:debug_print_object+0x 80/0xb0... [161.361347] debug_object_free +0xeb/0x110 [161.361362] i915_active_fini+0x14/0x130 [i915] [161.361866] referencias de versión+0xfe/0x1f0 [i915] [161.362543] i915_vma_parked+0x1db/0x380 [i915] .363129] __gt_park+0x121/0x230 [i915] [161.363515 ] ____intel_wakeref_put_last+0x1f/0x70 [i915] Se ha rastreado que eso sucede cuando otro subproceso desactiva el VMA dentro del asistente __active_retire(), después de que el contador activo del VMA ya se haya reducido a 0, pero antes de que se desactive la desactivación del objeto del VMA. reportado a la herramienta de depuración de objetos. Podríamos evitar esa ejecución serializando i915_active_fini() con __active_retire() a través de ref->tree_lock, pero eso no impediría que se use VMA, por ejemplo, desde __i915_vma_retire() llamado al final de __active_retire(), después de ese VMA ya ha sido liberado por un i915_vma_destroy() concurrente al regresar de i915_active_fini(). Entonces, deberíamos solucionar el problema a nivel de VMA, no en i915_active. Dado que __i915_vma_parked() se llama desde __gt_park() en la última colocación del wakeref del GT, el problema podría solucionarse manteniendo el wakeref del GT el tiempo suficiente para que __active_retire() se complete antes de que se libere el wakeref y se estacione el GT. Creo que el problema fue introducido por el commit d93939730347 ("drm/i915: Eliminar el recuento de vma") que movió una llamada a i915_active_fini() desde un i915_vma_release() eliminado, llamado en la última colocación del kref de VMA eliminado, a i915_vma_parked() ruta de procesamiento llamada en la última colocación de un wakeref GT. Sin embargo, su visibilidad para la herramienta de depuración de objetos fue suprimida por un error en i915_active que se solucionó dos semanas después con el commit e92eb246feb9 ("drm/i915/active: Reparar la activación del objeto de depuración que falta"). Un VMA asociado con una solicitud no adquiere un wakeref GT por sí solo. En cambio, depende de un wakeref mantenido directamente por el intel_context activo de la solicitud para un GT asociado con su VM, e indirectamente del wakeref del motor de ese intel_context si el motor pertenece al mismo GT que la VM del VMA. Esos wakerefs se liberan de forma asincrónica con la desactivación de VMA. Solucione el problema obteniendo un wakeref para el GT del VMA al activarlo y colocando ese wakeref solo después de que se desactive el VMA. Sin embargo, excluya el GTT global de esa ruta de procesamiento; de lo contrario, la GPU nunca quedará inactiva. Dado que se puede llamar a __i915_vma_retire() desde contextos atómicos, utilice la variante asíncrona de wakeref put. Además, para evitar la dependencia del bloqueo circular, tenga cuidado de adquirir el wakeref antes del mutex de VM cuando ambos sean necesarios. v7: agregue comentarios en línea con justificaciones para: - usar variantes sin seguimiento de intel_gt_pm_get/put() (Nirmoy), - usar la variante asíncrona de _put(), - no obtener el wakeref en caso de un GTT global, - obtener siempre el primer wakeref fuera de vm->mutex. ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: core: corrige el punto muerto en usb_deauthorize_interface() Entre las rutinas de devolución de llamada de archivos de atributos en drivers/usb/core/sysfs.c, la función interface_authorized_store() es la única que adquiere un bloqueo de dispositivo en un dispositivo antecesor: llama a usb_deauthorize_interface(), que bloquea el dispositivo USB principal de la interfaz. Esto conducirá a un punto muerto si otro proceso ya posee ese bloqueo e intenta eliminar la interfaz, ya sea mediante un cambio de configuración o porque el dispositivo se ha desconectado. Como parte del procedimiento de eliminación, device_del() espera a que se completen todas las devoluciones de llamadas de atributos sysfs en curso. Pero usb_deauthorize_interface() no se puede completar hasta que se haya liberado el bloqueo del dispositivo, y el bloqueo no se liberará hasta que haya finalizado la eliminación. El mecanismo proporcionado por sysfs para evitar este tipo de punto muerto es utilizar la función sysfs_break_active_protection(), que le dice a sysfs que no espere la devolución de llamada del atributo. Reportado y probado por: Yue Sun Reportado por: xingwei lee

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: corrige la regresión del directorio del host procfs no eliminado. el commit fc663711b944 ("scsi: core: elimina el directorio /proc/scsi/${proc_name} anteriormente") corrigió un error relacionado con carga/descarga de módulos, agregando una llamada a scsi_proc_hostdir_rm() en scsi_remove_host(). Pero eso llevó a una posible llamada duplicada a la rutina hostdir_rm(), ya que también se llama desde scsi_host_dev_release(). Eso desencadenó un informe de regresión, que luego se solucionó mediante el commit be03df3d4bfe ("scsi: core: Fix a procfs host directorio de eliminación de regresión"). La solución simplemente eliminó la llamada hostdir_rm() desde dev_release(). Pero sucede que este directorio proc se crea en scsi_host_alloc(), y esa función se "empareja" con scsi_host_dev_release(), mientras que scsi_remove_host() se empareja con scsi_add_host(). En otras palabras, parece que la razón para eliminar el directorio proc en dev_release() fue para cubrir casos en los que se asignó una estructura de host SCSI, pero la llamada a scsi_add_host() no ocurrió. Y ese patrón existe en algunas rutas de error, por ejemplo. Syzkaller provoca que, al utilizar un dispositivo USB sin formato, se produzca un error en el controlador de almacenamiento USB, en usb_stor_probe2(). Al verificar esa ruta, podemos ver que la etiqueta BadDevice conduce a scsi_host_put() después de una asignación de host SCSI, pero no hay ninguna llamada a scsi_add_host() en dicha ruta. Eso lleva a mensajes como este en dmesg (y una fuga de la estructura del proceso del host SCSI): usb-storage 4-1:87.51: Dispositivo de almacenamiento masivo USB detectado proc_dir_entry 'scsi/usb-storage' ya registrado ADVERTENCIA: CPU: 1 PID : 3519 en fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376 La solución adecuada parece seguir llamando a scsi_proc_hostdir_rm() en dev_release(), pero guárdela con la verificación de estado para SHOST_CREATED ; incluso hay un comentario en scsi_host_dev_release() que detalla que: dicho condicional está destinado a casos en los que se asignó el host SCSI pero no hubo llamadas a {add,remove}_host(), como el caso del almacenamiento USB. Esto es lo que proponemos aquí y con eso, la ruta de error del almacenamiento USB ya no activa la advertencia.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/i915/gt: Restablecer queue_priority_hint al estacionar Originalmente, con ejecución en orden estricto, podíamos completar la ejecución solo cuando la cola estaba vacía. La preferencia por ocupación permite el reemplazo de una solicitud activa que puede completarse antes de que HW procese la preferencia. Si eso sucede, la solicitud se retira de la cola, pero queue_priority_hint permanece configurada, lo que impide el envío directo hasta después de que se procese la siguiente interrupción de CS. Esta ejecución de prioridad a ocupación puede ser desencadenada por el latido del corazón, que también actuará como barrera de administración de energía y, al finalizar, nos permitirá dejar el HW inactivo. Podemos procesar la finalización del latido y comenzar a estacionar el motor antes del evento CS que restaura queue_priority_hint, lo que hace que falle la afirmación de que es MIN. <3>[ 166.210729] __engine_park:283 GEM_BUG_ON(motor->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1)) <0>[ 166.210781] Volviendo buffer ftrace: <0 >[ 166.210795] --------------------------------- ... <0>[ 167.302811] drm_fdin-1097 2 ..s1. 165741070us: trace_ports: 0000:00:02.0 rcs0: promover { ccid:20 1217:2 prio 0 } <0>[ 167.302861] drm_fdin-1097 2d.s2. 165741072us: execlists_submission_tasklet: 0000:00:02.0 rcs0: apropiación del último = 1217:2, prio = 0, sugerencia = 2147483646 <0> [167.302928] drm_fdin-1097 2d.s2. 165741072us: __i915_request_unsubmit: 0000:00:02.0 rcs0: valla 1217:2, actual 0 <0>[ 167.302992] drm_fdin-1097 2d.s2. 165741073us: __i915_request_submit: 0000:00:02.0 rcs0: valla 3:4660, actual 4659 <0>[ 167.303044] drm_fdin-1097 2d.s1. 165741076us: execlists_submission_tasklet: 0000:00:02.0 rcs0: contexto:3 programación de entrada, ccid:40 <0>[ 167.303095] drm_fdin-1097 2d.s1. 165741077us: trace_ports: 0000:00:02.0 rcs0: enviar { ccid:40 3:4660* prio 2147483646 } <0>[ 167.303159] kworker/-89 11..... 165741139us: i915_request_retire.part.0: 0000:00 :02.0 rcs0: valla c90:2, actual 2 <0>[ 167.303208] kworker/-89 11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: contexto:c90 desanclar <0>[ 167.303272] kworker/ -89 11..... 165741159us: i915_request_retire.part.0: 0000:00:02.0 rcs0: valla 1217:2, actual 2 <0>[ 167.303321] kworker/-89 11..... 165741166us: __intel_context_do_unpin: 0000:00:02.0 rcs0: contexto:1217 desanclar <0>[ 167.303384] kworker/-89 11..... 165741170us: i915_request_retire.part.0: 0000:00:02.0 rcs0: valla 3:4660, actual 4660 < 0>[ 167.303434] ktrabajador/-89 11d..1. 165741172us: __intel_context_retire: 0000:00:02.0 rcs0: contexto:1216 retirar tiempo de ejecución: { total:56028ns, avg:56028ns } <0>[ 167.303484] kworker/-89 11..... 165741198us: __engine_park: 0000:00: 02.0 rcs0: estacionado <0>[ 167.303534] -0 5d.H3. 165741207us: execlists_irq_handler: 0000:00:02.0 rcs0: rendimiento del semáforo: 00000040 <0>[ 167.303583] kworker/-89 11..... 165741397us: __intel_context_retire: 0000:00:02.0 s0: contexto: 1217 retirar el tiempo de ejecución: {total :325575ns, promedio:0ns } <0>[ 167.303756] kworker/-89 11..... 165741777us : __intel_context_retire: 0000:00:02.0 rcs0: contexto:c90 retirar tiempo de ejecución: { total:0ns, promedio:0ns } < 0>[ 167.303806] kworker/-89 11..... 165742017us : __engine_park: __engine_park:283 GEM_BUG_ON(motor->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1) ) <0>[ 167.303811] --------------------------------- <4>[ 167.304722] ---- --------[ cortar aquí ]------------ <2>[ 167.304725] ERROR del kernel en drivers/gpu/drm/i915/gt/intel_engine_pm.c:283! <4>[ 167.304731] código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI <4>[ 167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Contaminado: GW 6.8.0-rc2-CI_DRM_14193-gc655e0fd2804+ #1 <4>[ 167.304736] ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: validar el tamaño del búfer de solicitud en smb2_allocate_rsp_buf() El búfer de respuesta debe asignarse en smb2_allocate_rsp_buf antes de validar la solicitud. Pero los campos en el payload y el encabezado smb2 se usan en smb2_allocate_rsp_buf(). Este parche agrega una validación simple del tamaño del búfer para evitar posibles límites en el búfer de solicitud.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vmwgfx: desasignar la superficie antes de restablecerla en un estado plano. Cambiar a un nuevo estado plano requiere eliminar la referencia de todas las superficies retenidas. En el trabajo requerido para los cursores de mob, las superficies mapeadas comenzaron a almacenarse en caché, pero la variable que indica si la superficie está actualmente mapeada no se restableció. Esto provoca fallos ya que el estado duplicado, incorrectamente, indica que esa superficie está mapeada incluso cuando no hay ninguna superficie presente. Esto se debe a que después de eliminar la referencia a la superficie, es perfectamente posible que el avión esté respaldado por un bo en lugar de una superficie. Restablezca el indicador de superficie asignada al eliminar la referencia a la superficie del estado del plano para corregir las desreferencias nulas en la limpieza. Soluciona fallas en KDE KWin 6.0 en Wayland: Ups: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2 Nombre del hardware: VMware, Inc. VMware Virtual Platform/ Plataforma de referencia de escritorio 440BX, BIOS 6.00 12/11/2020 RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] Código: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc 48 8b b 3a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f> RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246 RAX: 0000000000000000 : ffff969d84cdcb00 RCX: 00000000000000027 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600 RBP: ffff969d4143dc50 R08: 0000000000000000 R09: ffffb6b98216f920 R10: 0000000000000003 R11: 9e7feb3b10 R12: 0000000000000000 R13: 0000000000000000 R14: 000000000000027b R15: ffff969d49c9fc00 FS: 00007f1e8f1b4180(0000) e75f00000(0000) knlGS:0000000000000000 CS: 0010 DS : 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 0000000104006004 CR4: 00000000003706f0 Seguimiento de llamadas: ? __morir+0x23/0x70 ? page_fault_oops+0x171/0x4e0? exc_page_fault+0x7f/0x180? asm_exc_page_fault+0x26/0x30? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] drm_atomic_helper_cleanup_planes+0x9b/0xc0 commit_tail+0xd1/0x130 drm_atomic_helper_commit+0x11a/0x140 drm_atomic_commit+0x97/0xd0 ? __pfx___drm_printfn_info+0x10/0x10 drm_atomic_helper_update_plane+0xf5/0x160 drm_mode_cursor_universal+0x10e/0x270 drm_mode_cursor_common+0x102/0x230 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 drm_ioctl_kernel+0xb2/0x110 drm_ioctl+0x26d/0x4b0 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 ? __pfx_drm_ioctl+0x10/0x10 vmw_generic_ioctl+0xa4/0x110 [vmwgfx] __x64_sys_ioctl+0x94/0xd0 do_syscall_64+0x61/0xe0 ? __x64_sys_ioctl+0xaf/0xd0 ? syscall_exit_to_user_mode+0x2b/0x40? do_syscall_64+0x70/0xe0? __x64_sys_ioctl+0xaf/0xd0 ? syscall_exit_to_user_mode+0x2b/0x40? do_syscall_64+0x70/0xe0? exc_page_fault+0x7f/0x180 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f1e93f279ed Código: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff f> RSP: 002b:00007ffca0faf600 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 55db876ed2c0 RCX: 00007f1e93f279ed RDX: 00007ffca0faf6c0 RSI: 00000000c02464bb RDI: 0000000000000015 RBP: 00007ffca0faf650 R08: 000055db87184010 R09: 0000000000000007 R10: 000055db886471a0 R11: 0000000000000246 R12: 00007ffca0faf6c0 R13: 0000c02464bb R14: 0000000000000015 R15: 00007ffca0faf790 Módulos vinculados en: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 fib_ipv6 nft_fib nft_reject_ine> CR2: 0000000000000028 ---[ seguimiento final 0000000000000000 ]--- RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] Código: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc 48 8b b3 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f> RSP: 0018:ffffb6b98216fa80 ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: qla2xxx: Corrección doble liberación de fcport El servidor fallaba después de LOGO porque fcport se liberaba dos veces. -----------[ cortar aquí ]----------- ¡ERROR del kernel en mm/slub.c:371! código de operación no válido: 0000 1 SMP PTI CPU: 35 PID: 4610 Comm: bash Kdump: cargado Contaminado: G OE --------- - - 4.18.0-425.3.1.el8.x86_64 #1 Nombre de hardware: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 03/09/2021 RIP: 0010:set_freepointer.part.57+0x0/0x10 RSP: 0018:ffffb07107027d90 EFLAGS: 00010246 RAX: RBX: ffff9cb7e332b9c0 RCX: ffff9cb7e3150400 RDX: 0000000000001f37 RSI : 0000000000000000 RDI: ffff9cb7c0005500 RBP: fffff693448c5400 R08: 0000000080000000 R09: 00000000000000009 R10: 0000000000000000 R11: 0000000132af0 R12: ffff9cb7c0005500 R13: ffff9cb7e3150000 R14: ffffffffc06990e0 R15: ffff9cb7ea85ea58 FS: 00007ff6b79c2740(0000) GS:ffff9cb8f7ec0000(000) 0) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055b426b7d700 CR3: 0000000169c18002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 00000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: kfree+0x238/0x250 _els_dcmd_sp_free+0x20 /0x230 [qla2xxx] ? qla24xx_els_dcmd_iocb+0x607/0x690 [qla2xxx] qla2x00_issue_logo+0x28c/0x2a0 [qla2xxx] ? qla2x00_issue_logo+0x28c/0x2a0 [qla2xxx] ? kernfs_fop_write+0x11e/0x1a0 Elimine una de las llamadas gratuitas y agregue una verificación de fcport válido. Utilice también la función qla2x00_free_fcport() en lugar de kfree().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: typec: tcpm: soluciona el problema de doble liberación en tcpm_port_unregister_pd() Cuando se cancela el registro de la capacidad de pd en tcpm, KASAN capturará el siguiente problema de doble liberación. La causa principal es que la misma capacidad se liberará dos veces, la primera vez se liberará mediante pd_capabilities_release() y la segunda vez se liberará explícitamente mediante tcpm_port_unregister_pd(). [3.988059] ERROR: KASAN: doble liberación en tcpm_port_unregister_pd+0x1a4/0x3dc [3.995001] Libre de dirección ffff0008164d3000 por tarea kworker/u16:0/10 [4.001206] [4.002712] CPU: 2 PID: 10 Co mm: ktrabajador/u16: 0 No contaminado 6.8.0-rc5-next-20240220-05616-g52728c567a55 #53 [4.012402] Nombre del hardware: Freescale i.MX8QXP MEK (DT) [4.017569] Cola de trabajo: events_unbound deferred_probe_work_func [4.023456] Seguimiento de llamadas: [ 4.025920] dump_backtrace+ 0x94/0xec [ 4.029629] show_stack+0x18/0x24 [ 4.032974] dump_stack_lvl+0x78/0x90 [ 4.036675] print_report+0xfc/0x5c0 [ 4.040289] kasan_report_invalid_free+0xa0/0xc0 [ 4 .044937] __kasan_slab_free+0x124/0x154 [ 4.049072] kfree+0xb4/ 0x1e8 [ 4.052069] tcpm_port_unregister_pd+0x1a4/0x3dc [ 4.056725] tcpm_register_port+0x1dd0/0x2558 [ 4.061121] tcpci_register_port+0x420/0x71c [ 4.065430] +0x118/0x2e0 Para solucionar el problema, esto eliminará kree() de tcpm_port_unregister_pd().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: core: corrige el punto muerto en el atributo sysfs "disable" del puerto. Las rutinas de devolución de llamada para mostrar y almacenar para el archivo del atributo sysfs "disable" en port.c adquieren el bloqueo del dispositivo para el puerto. dispositivo central principal. Esto puede causar problemas si otro proceso ha bloqueado el concentrador para eliminarlo o cambiar su configuración: Quitar el concentrador o cambiar su configuración requiere que se elimine la interfaz del concentrador, lo que requiere que se elimine el dispositivo del puerto, y device_del() espera hasta que todo Se han devuelto devoluciones de llamadas de atributos sysfs pendientes para los puertos. El bloqueo no podrá desbloquearse hasta entonces. Pero la rutina enable_show() o enable_store() no puede regresar hasta que haya adquirido el bloqueo. El punto muerto resultante se puede evitar llamando a sysfs_break_active_protection(). Esto hará que el núcleo de sysfs no espere a que regrese la rutina de devolución de llamada del atributo, lo que permitirá que continúe la eliminación. La desventaja es que después de realizar esta llamada, no hay garantía de que la estructura del centro no se desasignará en ningún momento. Para evitar esto, primero debemos adquirir una referencia llamando a hub_get().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: Corrección de doble liberación del puntero ha->vp_map Coverity scan informó un riesgo potencial de doble liberación del puntero ha->vp_map. ha->vp_map se liberó en qla2x00_mem_alloc() y nuevamente se liberó en la función qla2x00_mem_free(ha). Asigne NULL a vp_map y kfree se encargará de NULL.