Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/gup: gestionar páginas NULL en unpin_user_pages() La reciente incorporación dla gestión de "pofs" (páginas o folios) a gup tiene un defecto: supone que unpin_user_pages() gestiona páginas NULL en la matriz pages**. Ese no es el caso, como descubrí cuando ejecuté una nueva configuración en mi máquina de prueba. Solucione esto omitiendo las páginas NULL en unpin_user_pages(), tal como ya lo hace unpin_folios(). Detalles: al arrancar en x86 con "numa=fake=2 movablecore=4G" en Linux 6.12, y ejecutar esto: tools/testing/selftests/mm/gup_longterm ... obtengo el siguiente fallo: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000008 RIP: 0010:sanity_check_pinned_pages+0x3a/0x2d0 ... Seguimiento de llamadas: ? __die_body+0x66/0xb0 ? page_fault_oops+0x30c/0x3b0 ? do_user_addr_fault+0x6c3/0x720 ? irqentry_enter+0x34/0x60 ? exc_page_fault+0x68/0x100 ? asm_exc_page_fault+0x22/0x30 ? comprobación de integridad de páginas fijadas+0x3a/0x2d0 desanclar páginas de usuario+0x24/0xe0 comprobar y migrar páginas o folios movibles+0x455/0x4b0 __gup_longterm_locked+0x3bf/0x820 ? mmap_read_lock_killable+0x12/0x50 ? __pfx_mmap_read_lock_killable+0x10/0x10 pin_usuario_páginas+0x66/0xa0 gup_test_ioctl+0x358/0xb20 __se_sys_ioctl+0x6b/0xc0 hacer_llamada_al_sistema_64+0x7b/0x150 entrada_SYSCALL_64_después_de_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/numa: se corrige la pérdida de memoria debido a la sobrescritura de vma->numab_state [Descripción del problema] Al ejecutar el programa hackbench de LTP, kmemleak informa la siguiente pérdida de memoria. # /opt/ltp/testcases/bin/hackbench 20 thread 1000 Se ejecuta con 20*40 (== 800) tareas. # dmesg | grep kmemleak ... kmemleak: 480 nuevas fugas de memoria sospechosas (consulte /sys/kernel/debug/kmemleak) kmemleak: 665 nuevas fugas de memoria sospechosas (consulte /sys/kernel/debug/kmemleak) # cat /sys/kernel/debug/kmemleak objeto sin referencia 0xffff888cd8ca2c40 (tamaño 64): comm "hackbench", pid 17142, jiffies 4299780315 volcado hexadecimal (primeros 32 bytes): ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00 .tI.....LI.... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ seguimiento inverso (crc bff18fd4): [] __kmalloc_cache_noprof+0x2f9/0x3f0 [] tarea_numa_work+0x725/0xa00 [] tarea_work_run+0x58/0x90 [] llamada_al_sistema_salir_al_modo_usuario+0x1c8/0x1e0 [] hacer_llamada_al_sistema_64+0x85/0x150 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e ... Este problema se puede reproducir consistentemente en tres servidores diferentes: * un servidor de 448 núcleos * un servidor de 256 núcleos * un servidor de 192 núcleos [Causa raíz] Dado que el programa hackbench crea múltiples subprocesos (junto con el argumento de comando 'thread'), dos o más núcleos pueden acceder simultáneamente a un VMA compartido. Cuando dos o más núcleos observan que vma->numab_state es NULL al mismo tiempo, se sobrescribirá vma->numab_state. Aunque el código actual garantiza que solo un subproceso escanee los VMA en un solo 'numa_scan_period', puede haber una posibilidad de que otro subproceso ingrese en el siguiente 'numa_scan_period' mientras no hayamos obtenido hasta la asignación de numab_state [1]. Tenga en cuenta que el comando `/opt/ltp/testcases/bin/hackbench 50 process 1000` no puede reproducir el problema. Esto se ha verificado con más de 200 ejecuciones de pruebas. [Solución] Utilice la operación atómica cmpxchg para asegurarse de que solo un subproceso ejecute la asignación vma->numab_state. [1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_packet: evitar errores después de sock_init_data() en packet_create() Después de sock_init_data(), el objeto sk asignado se adjunta al objeto sock proporcionado. En caso de error, packet_create() libera el objeto sk dejando el puntero colgando en el objeto sock al regresar. Es posible que algún otro código intente usar este puntero y provoque un error de use-after-free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se corrige el acceso fuera de los límites en 'dcn21_link_encoder_create' Se identificó un problema en la función dcn21_link_encoder_create donde podría ocurrir un acceso fuera de los límites cuando se usó el índice hpd_source para hacer referencia a la matriz link_enc_hpd_regs. Esta matriz tiene un tamaño fijo y el índice no se estaba verificando con los límites de la matriz antes de acceder a ella. Esta corrección agrega una verificación condicional para garantizar que el índice hpd_source esté dentro del rango válido de la matriz link_enc_hpd_regs. Si el índice está fuera de los límites, la función ahora devuelve NULL para evitar un comportamiento indefinido. Referencias: [ 65.920507] ------------[ cortar aquí ]------------ [ 65.920510] UBSAN: array-index-out-of-bounds en drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn21/dcn21_resource.c:1312:29 [ 65.920519] el índice 7 está fuera de rango para el tipo 'dcn10_link_enc_hpd_registers [5]' [ 65.920523] CPU: 3 PID: 1178 Comm: modprobe Tainted: G OE 6.8.0-cleanershaderfeatureresetasdntipmi200nv2132 #13 [ 65.920525] Nombre del hardware: AMD Majolica-RN/Majolica-RN, BIOS WMJ0429N_Semanal_20_04_2 29/04/2020 [ 65.920527] Seguimiento de llamadas: [ 65.920529] [ 65.920532] dump_stack_lvl+0x48/0x70 [ 65.920541] dump_stack+0x10/0x20 [ 65.920543] __ubsan_handle_out_of_bounds+0xa2/0xe0 [ 65.920549] dcn21_link_encoder_create+0xd9/0x140 [amdgpu] [ 65.921009] link_create+0x6d3/0xed0 [amdgpu] [ 65.921355] dmi_matches+0xa0/0x220 [65.922004] amdgpu_dm_init+0x2b6/0x2c90 [amdgpu] [65.922342] ? console_unlock+0x77/0x120 [65.922348] ? dev_printk_emit+0x86/0xb0 [ 65.922354] dm_hw_init+0x15/0x40 [amdgpu] [ 65.922686] amdgpu_device_init+0x26a8/0x33a0 [amdgpu] [ 65.922921] amdgpu_driver_load_kms+0x1b/0xa0 [amdgpu] [ 65.923087] amdgpu_pci_probe+0x1b7/0x630 [amdgpu] [ 65.923087] local_pci_probe+0x4b/0xb0 [ 65.923087] pci_device_probe+0xc8/0x280 [ 65.923087] realmente_probe+0x187/0x300 [ 65.923087] __driver_probe_device+0x85/0x130 [ 65.923087] driver_probe_device+0x24/0x110 [ 65.923087] __driver_attach+0xac/0x1d0 [ 65.923087] ? __pfx___driver_attach+0x10/0x10 [ 65.923087] bus_para_cada_dispositivo+0x7d/0xd0 [ 65.923087] driver_attach+0x1e/0x30 [ 65.923087] bus_add_driver+0xf2/0x200 [ 65.923087] driver_register+0x64/0x130 [ 65.923087] ? __pfx_amdgpu_init+0x10/0x10 [amdgpu] [ 65.923087] __pci_register_driver+0x61/0x70 [ 65.923087] amdgpu_init+0x7d/0xff0 [amdgpu] [ 65.923087] hacer_una_llamada_init+0x49/0x310 [ 65.923087] ? kmalloc_trace+0x136/0x360 [ 65.923087] hacer_init_module+0x6a/0x270 [ 65.923087] cargar_módulo+0x1fce/0x23a0 [ 65.923087] iniciar_módulo_desde_archivo+0x9c/0xe0 [ 65.923087] ? módulo_de_inicio_desde_archivo+0x9c/0xe0 [ 65.923087] módulo_de_inicio_idempotente+0x179/0x230 [ 65.923087] módulo_de_finición_del_sistema_x64+0x5d/0xa0 [ 65.923087] llamada_al_sistema_64+0x76/0x120 [ 65.923087] llamada_al_sistema_64_después_de_hwframe+0x6e/0x76 [ 65.923087] RIP: 0033:0x7f2d80f1e88d [ 65.923087] Código: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 [ 65.923087] RSP: 002b:00007ffc7bc1aa78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 65.923087] RAX: ffffffffffffffda RBX: 0000564c9c1db130 RCX: 00007f2d80f1e88d [ 65.923087] RDX: 0000000000000000 RSI: 0000564c9c1e5480 RDI: 000000000000000f [ 65.923087] RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000002 [ 65.923087] R10: 000000000000000f R11: 0000000000000246 R12: 0000564c9c1e5480 [ 65.923087] R13: 0000564c9c1db260 R14: 0000000000000000 R15: 0000564c9c1e54b0 [ 65.923087] [ 65.923927] ---[ fin del seguimiento ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kcsan: Convertir report_filterlist_lock en un raw_spinlock Ran Xiaokai informa que con un kernel PREEMPT_RT habilitado para KCSAN, podemos ver símbolos como: | ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:48 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 | preempt_count: 10002, esperado: 0 | Profundidad de anidación de RCU: 0, esperado: 0 | no hay bloqueos mantenidos por swapper/1/0. | Marca de evento irq: 156674 | hardirqs habilitados por última vez en (156673): [] do_idle+0x1f9/0x240 | hardirqs se deshabilitó por última vez en (156674): [] sysvec_apic_timer_interrupt+0x14/0xc0 | softirqs se habilita por última vez en (0): [] copy_process+0xfc7/0x4b60 | softirqs se deshabilitó por última vez en (0): [<000000000000000>] 0x0 | Preempción deshabilitada en: | [] paint_ptr+0x2a/0x90 | CPU: 1 UID: 0 PID: 0 Comm: swapper/1 No contaminado 6.11.0+ #3 | Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 01/04/2014 | Seguimiento de llamadas: | | dump_stack_lvl+0x7e/0xc0 | dump_stack+0x1d/0x30 | __might_resched+0x1a2/0x270 | rt_spin_lock+0x68/0x170 | kcsan_skip_report_debugfs+0x43/0xe0 | print_report+0xb5/0x590 | kcsan_report_known_origin+0x1b1/0x1d0 | kcsan_setup_watchpoint+0x348/0x650 | En caso de detectarse una ejecución de datos, la lógica de informes de KCSAN comprueba si debe filtrar el informe. Esa lista está protegida por el spinlock report_filterlist_lock *no sin procesar* que puede estar inactivo en los núcleos RT. Dado que KCSAN puede informar ejecucións de datos en cualquier contexto, conviértalo en un spinlock sin procesar. Esto requiere tener cuidado con el momento de asignar memoria para la lista de filtros en sí, lo que se puede hacer a través de la interfaz debugfs de KCSAN. La modificación concurrente de la lista de filtros a través de debugfs debería ser poco frecuente: la estrategia elegida es preasignar memoria de manera optimista antes de la sección crítica y descartarla si no se utiliza.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: se corrige la escritura en mapas OOB al eliminar elementos Jordy dice: "En la función xsk_map_delete_elem, un entero sin signo (map->max_entries) se compara con un entero con signo controlado por el usuario (k). Debido a la conversión de tipo implícita, un valor sin signo grande para map->max_entries puede eludir la comprobación de los límites prevista: if (k >= map->max_entries) return -EINVAL; Esto permite que k contenga un valor negativo (entre -2147483648 y -2), que luego se utiliza como un índice de matriz en m->xsk_map[k], lo que da como resultado un acceso fuera de los límites. spin_lock_bh(&m->lock); map_entry = &m->xsk_map[k]; // Entrada de mapa fuera de los límites old_xs = unrcu_pointer(xchg(map_entry, NULL)); // Oob write if (old_xs) xsk_map_sock_delete(old_xs, map_entry); spin_unlock_bh(&m->lock); La operación xchg se puede utilizar para provocar una escritura fuera de los límites. Además, la map_entry no válida pasada a xsk_map_sock_delete puede provocar una mayor corrupción de la memoria. " De hecho, da como resultado el siguiente error: [76612.897343] ERROR: no se puede gestionar la falla de página para la dirección: ffffc8fc2e461108 [76612.904330] #PF: acceso de escritura del supervisor en modo kernel [76612.909639] #PF: error_code(0x0002) - página no presente [76612.914855] PGD 0 P4D 0 [76612.917431] Ups: Ups: 0002 [#1] PREEMPT SMP [76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out No contaminado 6.12.0-rc1+ #470 [76612.929189] Nombre del hardware: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 19/03/2019 [76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60 [76612.944738] Código: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 y siguientes <48> 87 3e 48 85 y siguientes 74 05 e8 16 y siguientes y siguientes y siguientes 4c 89 e7 e8 3e bc 05 00 31 [76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246 [76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000 [76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 00000000000000000 [76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007 [76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8 [76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0 [76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000 [76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0 [76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 000000000000000 [76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [76613.041086] PKRU: 55555554 [76613.043842] Seguimiento de llamadas: [76613.046331] [76613.048468] ? __die+0x20/0x60 [76613.051581] ? error_de_página_oops+0x15a/0x450 [76613.055747] ? búsqueda_extable+0x22/0x30 [76613.059649] ? búsqueda_bpf_extables+0x5f/0x80 [76613.063988] ? error_de_página_exc+0xa9/0x140 [76613.067975] ? error_de_página_exc+0x22/0x30 [76613.072229] ? ¿xsk_map_delete_elem+0x2d/0x60 [76613.076573] ? xsk_map_delete_elem+0x23/0x60 [76613.080914] __sys_bpf+0x19b7/0x23c0 [76613.084555] __x64_sys_bpf+0x1a/0x20 [76613.088194] hacer_syscall_64+0x37/0xb0 [76613.091832] entrada_SYSCALL_64_after_hwframe+0x4b/0x53 [76613.096962] RIP: 0033:0x7f80b6d1e88d [76613.100592] Código: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 [76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141 [76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d [76613.142632] RDX: 000000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003 [76613.153967] ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw88: use ieee80211_purge_tx_queue() para purgar TX skb Al eliminar módulos del kernel mediante: rmmod rtw88_8723cs rtw88_8703b rtw88_8723x rtw88_sdio rtw88_core El controlador usa skb_queue_purge() para purgar TX skb, pero no informa el estado de la tx, lo que provoca la advertencia "¡Tiene marcos de reconocimiento pendientes!". Use ieee80211_purge_tx_queue() para corregir esto. Dado que ieee80211_purge_tx_queue() no toma bloqueos, para evitar ejecucións entre el trabajo de TX y la cola de purga de TX, vacíe y destruya el trabajo de TX con anticipación. wlan0: desautenticando desde aa:f5:fd:60:4c:a8 por elección local (Razón: 3=DEAUTH_LEAVING) ------------[ cortar aquí ]------------ ¡Hay marcos de reconocimiento pendientes! ADVERTENCIA: CPU: 3 PID: 9232 en net/mac80211/main.c:1691 ieee80211_free_ack_frame+0x5c/0x90 [mac80211] CPU: 3 PID: 9232 Comm: rmmod Contaminado: GC 6.10.1-200.fc40.aarch64 #1 Nombre del hardware: pine64 Pine64 PinePhone Braveheart (1.1)/Pine64 PinePhone Braveheart (1.1), BIOS 2024.01 01/01/2024 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ieee80211_free_ack_frame+0x5c/0x90 [mac80211] lr : ieee80211_free_ack_frame+0x5c/0x90 [mac80211] sp : ffff80008c1b37b0 x29: ffff80008c1b37b0 x28: ffff000003be8000 x27: 0000000000000000 x26: 0000000000000000 x25: ffff000003dc14b8 x24: ffff80008c1b37d0 x23: ffff000000ff9f80 x22: 0000000000000000 x21: 000000007fffffff x20: ffff80007c7e93d8 x19: ffff00006e66f400 x18: 0000000000000000 x17: ffff7ffffd2b3000 x16: ffff800083fc0000 x15: 0000000000000000 x14: 0000000000000000 x13: 2173656d61726620 x12: 6b636120676e6964 x11: 000000000000000 x10: 000000000000005d x9: ffff8000802af2b0 x8: ffff80008c1b3430 x7: 00000000000000001 x6 : 0000000000000001 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003be8000 Rastreo de llamadas: ieee80211_free_ack_frame+0x5c/0x90 [mac80211] idr_for_each+0x74/0x110 ieee80211_free_hw+0x44/0xe8 [mac80211] rtw_sdio_remove+0x9c/0xc0 [rtw88_sdio] sdio_bus_remove+0x44/0x180 device_remove+0x54/0x90 device_release_driver_internal+0x1d4/0x238 driver_detach+0x54/0xc0 bus_remove_driver+0x78/0x108 driver_unregister+0x38/0x78 sdio_unregister_driver+0x2c/0x40 rtw_8723cs_driver_exit+0x18/0x1000 [rtw88_8723cs] __do_sys_delete_module.isra.0+0x190/0x338 __arm64_sys_delete_module+0x1c/0x30 invocar_llamada_al_sistema+0x74/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x138 el0t_64_sync+0x194/0x198 ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: se corrige el error shift-out-of-bounds en dbSplit. Cuando dmt_budmin es menor que cero, provoca errores en las etapas posteriores. Se agregó una verificación para devolver un error de antemano en dbAllocCtl.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: arreglo de array-index-out-of-bounds en dtReadFirst El valor de stbl a veces puede estar fuera de los límites debido a un sistema de archivos defectuoso. Se agregó una verificación con el retorno apropiado del código de error en ese caso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath10k: evitar error de puntero NULL durante la eliminación de sdio Al ejecutar 'rmmod ath10k', ath10k_sdio_remove() liberará la cola de trabajo de sdio mediante destroy_workqueue(). Pero si CONFIG_INIT_ON_FREE_DEFAULT_ON está configurado en sí, se producirá un pánico del kernel: Rastreo de llamada: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c Esto se debe a que durante 'rmmod ath10k', ath10k_sdio_remove() llamará a ath10k_core_destroy() antes de destroy_workqueue(). wiphy_dev_release() finalmente se llamará en ath10k_core_destroy(). Esta función liberará la estructura cfg80211_registered_device *rdev y todos sus miembros, incluidos wiphy, dev y el puntero de sdio workqueue. Luego, el puntero de sdio workqueue se establecerá en NULL debido a CONFIG_INIT_ON_FREE_DEFAULT_ON. Después de liberar el dispositivo, destroy_workqueue() usará el puntero NULL y luego se producirá el pánico del kernel. Rastreo de llamadas: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue Es necesario llamar a destroy_workqueue() antes de ath10k_core_destroy(), primero liberar el búfer de la cola de trabajo y luego liberar el puntero de la cola de trabajo mediante ath10k_core_destroy(). Este orden coincide con el orden de la ruta de error en ath10k_sdio_probe(). No se pondrá en cola ningún trabajo en la cola de trabajo de sdio entre su destrucción y la llamada a ath10k_core_destroy(). Según la pila de llamadas anterior, el motivo es el siguiente: solo ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() y ath10k_sdio_irq_disable() pondrán en cola el trabajo en la cola de trabajo de sdio. El temporizador de suspensión se eliminará antes de ath10k_core_destroy() en ath10k_hif_power_down(). ath10k_sdio_irq_disable() solo se llamará en ath10k_hif_stop(). ath10k_core_unregister() llamará a ath10k_hif_power_down() para detener el bus hif, por lo que ya no se llamará ath10k_sdio_hif_tx_sg(). Probado en: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: inet6: no deje un puntero sk colgando en inet6_create() sock_init_data() adjunta el puntero sk asignado al objeto sock proporcionado. Si inet6_create() falla más tarde, se libera el objeto sk, pero el objeto sock conserva el puntero sk colgando, lo que puede provocar un use-after-free más adelante. Borre el puntero sk sock en caso de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: inet: no deje un puntero sk colgando en inet_create() sock_init_data() adjunta el objeto sk asignado al objeto sock proporcionado. Si inet_create() falla más tarde, el objeto sk se libera, pero el objeto sock conserva el puntero colgando, lo que puede crear un use-after-free más tarde. Borre el puntero sk en el objeto sock en caso de error.