Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/guc_submit: corrige la ejecución alrededor de suspend_pending Actualmente en algunos casos de prueba podemos activar: xe 0000:03:00.0: [drm] ¡La afirmación `exec_queue_destroyed(q)` falló! .... ADVERTENCIA: CPU: 18 PID: 2640 en drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Estado de motor inesperado 0x00a1, guc_id=57 Si observamos un fragmento de ftrace correspondiente a este id de GuC, podemos ver: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, código de operación=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, ancho=1, guc_id=57, guc_state=0x29, indicadores=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, ancho=1, guc_id=57, guc_state=0x29, indicadores=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 Parece que intentamos suspender la cola (opcode=3), configurando suspend_pending y activando un disable_scheduling. Luego, el usuario cierra la cola. Sin embargo, el cierre también señalará con fuerza la valla de suspensión después de matar la cola, más tarde, cuando la respuesta G2H para deshabilitar_programación regrese, ahora hemos borrado suspend_pending al señalar la valla de suspensión, por lo que deshabilitar_programación ahora intenta incorrectamente también anular el registro de la cola. Esto genera advertencias ya que la cola aún no se ha marcado para su destrucción. También parece que desencadenamos errores más tarde al intentar anular el registro dos veces de la misma cola. Para solucionar esto, modifique el orden al gestionar la respuesta para garantizar que no compitamos con un deshabilitar_programación que en realidad no tenía la intención de realizar una anulación del registro. La ruta de destrucción ahora también debería esperar correctamente cualquier pendiente_deshabilitar antes de marcar como destruida. (seleccionado de el commit f161809b362f027b6d72bd998e47f8f0bad60a2e)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrección de slab de use-after-free [ +0.000021] ERROR: KASAN: slab-use-after-free en drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000027] Lectura de tamaño 8 en la dirección ffff8881b8605f88 por la tarea amd_pci_unplug/2147 [ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug No contaminado 6.10.0+ #1 [ +0.000016] Nombre del hardware: Nombre del producto del sistema ASUS/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000016] Rastreo de llamadas: [ +0.000008] [ +0.000009] dump_stack_lvl+0x76/0xa0 [ +0.000017] print_report+0xce/0x5f0 [ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] ? srso_return_thunk+0x5/0x5f [ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200 [ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] kasan_report+0xbe/0x110 [ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000023] __asan_report_load8_noabort+0x14/0x30 [ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? enable_work+0x124/0x220 [ +0.000015] ? __pfx_enable_work+0x10/0x10 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? free_large_kmalloc+0x85/0xf0 [ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched] [ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu] [ +0.000735] ? __kasan_check_read+0x11/0x20 [ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu] [ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu] [ +0.000679] ? mutex_unlock+0x80/0xe0 [ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu] [ +0.000662] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? mutex_unlock+0x80/0xe0 [ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu] [ +0.000663] drm_minor_release+0xc9/0x140 [drm] [ +0.000081] drm_release+0x1fd/0x390 [drm] [ +0.000082] __fput+0x36c/0xad0 [ +0.000018] __fput_sync+0x3c/0x50 [ +0.000014] __x64_sys_close+0x7d/0xe0 [ +0.000014] x64_sys_call+0x1bc6/0x2680 [ +0.000014] do_syscall_64+0x70/0x130 [ +0.000014] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190 [ +0.000015] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit+0x43/0x50 [ +0.000012] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? exc_page_fault+0x7c/0x110 [ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000014] RIP: 0033:0x7ffff7b14f67 [ +0.000013] Código: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff [ +0.000026] RSP: 002b:00007ffffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67 [ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003 [ +0.000014] RBP: 00007ffffffffe3a0 R08: 0000555555569890 R09: 0000000000000000 [ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffffffffe5c8 [ +0.000013] R13: 0000555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040 [ +0.000020] [ +0.000016] Asignado por la tarea 383 en la CPU 7 en 26.880319s: [ +0.000014] kasan_save_stack+0x28/0x60 [ +0.000008] kasan_save_track+0x18/0x70 [ +0.000007] kasan_save_alloc_info+0x38/0x60 [ +0.000007] __kasan_kmalloc+0xc1/0xd0 [ +0.000007] kmalloc_trace_noprof+0x180/0x380 [ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched] [ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu] [ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu] [ +0.000662] amdgpu_pci_p ---truncado---

Se ha encontrado una vulnerabilidad clasificada como crítica en Overtek OT-E801G OTE801G65.1.1.0. Esta vulnerabilidad afecta al código desconocido del archivo /diag_ping.cmd?action=test&interface=ppp0.1&ipaddr=8.8.8.8%26%26cat%20/etc/passwd&ipversion=4&sessionKey=test. La manipulación conduce a la inyección de comandos del sistema operativo. El ataque puede iniciarse de forma remota. El exploit ha sido divulgado al público y puede utilizarse. Se contactó al proveedor con anticipación sobre esta divulgación, pero no respondió de ninguna manera.

Se ha encontrado una vulnerabilidad clasificada como problemática en Amcrest IP2M-841B, IP2M-841W, IPC-IP2M-841B, IPC-IP3M-943B, IPC-IP3M-943S, IPC-IP3M-HX2B e IPC-IPM-721S hasta 20241211. Afecta a una parte desconocida del archivo /web_caps/webCapsConfig del componente Web Interface. La manipulación conduce a la divulgación de información. Es posible iniciar el ataque de forma remota. El exploit se ha divulgado al público y puede utilizarse. Se contactó al proveedor con anticipación sobre esta divulgación, pero no respondió de ninguna manera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Omitir desinfección de TID de Rx para peer propio Durante la creación del peer, se realiza la configuración de dp para el peer donde se actualiza el TID de Rx para todos los TID. El objeto peer para el peer propio no pasará por la configuración de dp. Cuando el núcleo se detiene, se realiza la desinfección de dp para todos los peers. Durante la desinfección, se accede a rx_tid::ab, lo que provoca el siguiente seguimiento de pila para el peer propio. ADVERTENCIA: CPU: 6 PID: 12297 en drivers/net/wireless/ath/ath12k/dp_rx.c:851 Seguimiento de llamadas: __warn+0x7b/0x1a0 ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k] report_bug+0x10b/0x200 handle_bug+0x3f/0x70 exc_invalid_op+0x13/0x60 asm_exc_invalid_op+0x16/0x20 ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k] ath12k_dp_rx_frags_cleanup+0xca/0xe0 [ath12k] ath12k_dp_rx_peer_tid_cleanup+0x39/0xa0 [ath12k] ath12k_mac_peer_cleanup_all+0x61/0x100 [ath12k] ath12k_core_halt+0x3b/0x100 [ath12k] ath12k_core_reset+0x494/0x4c0 [ath12k] El objeto sta en el peer se actualizará cuando se cree el peer remoto. Por lo tanto, use peer::sta para detectar el peer propio y omitir la desinfección. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udmabuf: cambia la matriz de folios de kmalloc a kvmalloc Cuando PAGE_SIZE es 4096, MAX_PAGE_ORDER es 10, en una máquina de 64 bits, page_alloc solo admite 4 MB. Si es mayor, se activa esta advertencia y se devuelve NULL. udmabuf puede cambiar el límite de tamaño. Si lo cambia a 3072 (3 GB) y luego asigna 3 GB, udmabuf no podrá crearlo. [ 4080.876581] ------------[ cortar aquí ]------------ [ 4080.876843] ADVERTENCIA: CPU: 3 PID: 2015 en mm/page_alloc.c:4556 __alloc_pages+0x2c8/0x350 [ 4080.878839] RIP: 0010:__alloc_pages+0x2c8/0x350 [ 4080.879470] Seguimiento de llamadas: [ 4080.879473] [ 4080.879473] ? __alloc_pages+0x2c8/0x350 [ 4080.879475] ? __warn.cold+0x8e/0xe8 [ 4080.880647] ? __alloc_pages+0x2c8/0x350 [ 4080.880909] ? report_bug+0xff/0x140 [ 4080.881175] ? handle_bug+0x3c/0x80 [ 4080.881556] ? exc_invalid_op+0x17/0x70 [ 4080.881559] ? asm_exc_invalid_op+0x1a/0x20 [ 4080.882077] ? udmabuf_create+0x131/0x400 Debido a MAX_PAGE_ORDER, kmalloc puede asignar un máximo de 4096 * (1 << 10), 4 MB de memoria, cada entrada de la matriz es un puntero (8 bytes), por lo que puede guardar 524288 páginas (2 GB). Además, es posible que no se garantice que se pueda aplicar el pedido costoso (pedido 3) debido a la fragmentación. Este parche cambia la matriz udmabuf para usar kvmalloc_array, lo que permite que la asignación se convierta en una función alternativa de vmalloc, lo que puede garantizar la asignación para cualquier tamaño y no afecta el rendimiento de las asignaciones de kmalloc.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: hyperv: optimizar la sonda del controlador para evitar problemas con devres Se encontró que descargar el módulo 'hid_hyperv' da como resultado una queja de devres: ... hv_vmbus: anulando el registro del controlador hid_hyperv ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 2 PID: 3983 en drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0 ... Seguimiento de llamadas: ? devres_release_group+0x1f2/0x2c0 ? __warn+0xd1/0x1c0 ? devres_release_group+0x1f2/0x2c0 ? report_bug+0x32a/0x3c0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? grupo_liberación_devres+0x1f2/0x2c0 ? grupo_liberación_devres+0x90/0x2c0 ? rcu_is_watching+0x15/0xb0 ? __pfx_grupo_liberación_devres+0x10/0x10 eliminación_dispositivo_hid+0xf5/0x220 controlador_liberación_dispositivo_interno+0x371/0x540 ? klist_put+0xf3/0x170 eliminación_dispositivo_bus+0x1f1/0x3f0 dispositivo_del+0x33f/0x8c0 ? __pfx_dispositivo_del+0x10/0x10 ? cleanup_srcu_struct+0x337/0x500 hid_destroy_device+0xc8/0x130 mousevsc_remove+0xd2/0x1d0 [hid_hyperv] device_release_driver_internal+0x371/0x540 driver_detach+0xc5/0x180 bus_remove_driver+0x11e/0x2a0 ? __mutex_unlock_slowpath+0x160/0x5e0 vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus] ... Y el problema parece ser que el grupo devres correspondiente no está asignado. Normalmente, devres_open_group() se llama desde __hid_device_probe() pero el controlador HID de Hyper-V anula 'hid_dev->driver' con el stub 'mousevsc_hid_driver' y básicamente vuelve a implementar __hid_device_probe() llamando a hid_parse() y hid_hw_start() pero no a devres_open_group(). hid_device_probe() no llama a __hid_device_probe() para ello. Más tarde, cuando se elimina el controlador, hid_device_remove() llama a devres_release_group() ya que no verifica si hdev->driver se anuló inicialmente o no. El problema parece estar relacionado con el commit 62c68e7cee33 ("HID: garantizar la liberación oportuna de los recursos asignados al controlador") pero el commit en sí parece ser correcta. Solucione el problema eliminando la anulación de 'hid_dev->driver' y utilizando hid_register_driver()/hid_unregister_driver() en su lugar. Como alternativa, habría sido posible confiar en la gestión predeterminado, pero HID_CONNECT_DEFAULT implica HID_CONNECT_HIDRAW y no parece funcionar para mousevsc tal como está.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rcu/nocb: Corregir la barrera RCU omitida al descargar Actualmente, ejecutar la prueba rcutorture con torture_type=rcu fwd_progress=8 n_barrier_cbs=8 nocbs_nthreads=8 nocbs_toggle=100 onoff_interval=60 test_boost=2, activará la siguiente advertencia: ADVERTENCIA: CPU: 19 PID: 100 en kernel/rcu/tree_nocb.h:1061 rcu_nocb_rdp_deoffload+0x292/0x2a0 RIP: 0010:rcu_nocb_rdp_deoffload+0x292/0x2a0 Rastreo de llamadas: ? __warn+0x7e/0x120 ? rcu_nocb_rdp_deoffload+0x292/0x2a0? report_bug+0x18e/0x1a0? handle_bug+0x3d/0x70? exc_invalid_op+0x18/0x70? asm_exc_invalid_op+0x1a/0x20? rcu_nocb_rdp_deoffload+0x292/0x2a0 rcu_nocb_cpu_deoffload+0x70/0xa0 rcu_nocb_toggle+0x136/0x1c0? __pfx_rcu_nocb_toggle+0x10/0x10 kthread+0xd1/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 CPU0 CPU2 CPU3 //rcu_nocb_toggle //nocb_cb_wait //rcutorture // desconecta la CPU1 // procesa el rdp de la CPU1 rcu_barrier() rcu_segcblist_entrain() rcu_segcblist_add_len(1); // len == 2 // poner en cola la barrera // devolución de llamada a rdp->cblist de CPU1 rcu_do_batch() // invocar rdp->cblist de CPU1 // devolución de llamada rcu_barrier_callback() rcu_barrier() mutex_lock(&rcu_state.barrier_mutex); // todavía se ve len == 2 // poner en cola la barrera // devolución de llamada a rdp->cblist de CPU1 rcu_segcblist_entrain() rcu_segcblist_add_len(1); // len == 3 // decrementar len rcu_segcblist_add_len(-2); kthread_parkme() // rdp->cblist de CPU1 len == 1 // Advertir porque todavía hay una barrera pendiente // activar la advertencia WARN_ON_ONCE(rcu_segcblist_n_cbs(&rdp->cblist)); cpus_read_unlock(); // esperar a que la CPU1 se conecte e // invocar la devolución de llamada de barrera en // la CPU1 rdp's->cblist wait_for_completion(&rcu_state.barrier_completion); // descargar la CPU4 cpus_read_lock() rcu_barrier() mutex_lock(&rcu_state.barrier_mutex); // bloquear en barrier_mutex // esperar a que rcu_barrier() en // la CPU3 desbloquee barrier_mutex // pero la CPU3 desbloquea barrier_mutex // necesita esperar a que la CPU1 se conecte // cuando la CPU1 se conecte se bloqueará en cpus_write_lock El escenario anterior no solo activará un WARN_ON_ONCE(), sino que también activará un bloqueo. Gracias al bloqueo de nocb, un segundo rcu_barrier() en una CPU fuera de línea observará el contador de devolución de llamadas reducido a 0 y ahorrará la puesta en cola de devolución de llamadas, o rcuo observará la nueva devolución de llamada y mantendrá rdp->nocb_cb_sleep en falso. Por lo tanto, verifique rdp->nocb_cb_sleep antes de estacionar para asegurarse de que no haya más rcu_barrier() esperando en el rdp.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: controladores: soc: xilinx: agregue el kfree faltante en xlnx_add_cb_for_suspend() Si no podemos asignar memoria para cb_data mediante kmalloc, la asignación de memoria para eve_data nunca se libera, agregue el kfree() faltante en la ruta de gestión de errores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hfsplus: no consultar el tamaño del bloque lógico del dispositivo varias veces Los tamaños de bloque de los dispositivos pueden cambiar. Uno de estos casos es un dispositivo de bucle mediante el uso de ioctl LOOP_SET_BLOCK_SIZE. Si bien esto puede causar otros problemas como el rechazo de IO, en el caso de hfsplus, asignará un bloque utilizando ese tamaño y potencialmente escribirá fuera de los límites cuando hfsplus_read_wrapper llame a hfsplus_submit_bio y la última función lea un io_size diferente. El uso de un nuevo min_io_size establecido inicialmente en sb_min_blocksize funciona para los propósitos de la solución original, ya que se establecerá en el máximo entre HFSPLUS_SECTOR_SIZE y el primer tamaño de bloque lógico visto. Todavía usamos el máximo entre HFSPLUS_SECTOR_SIZE y min_io_size en caso de que este último no esté inicializado. Probado montando un sistema de archivos hfsplus con tamaños de bloque de bucle 512, 1024 y 4096. El informe KASAN producido antes de la corrección se ve así: [ 419.944641] ========================================================================= [ 419.945655] ERROR: KASAN: slab-use-after-free en hfsplus_read_wrapper+0x659/0xa0a [ 419.946703] Lectura de tamaño 2 en la dirección ffff88800721fc00 por la tarea repro/10678 [ 419.947612] [ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro No contaminado 6.12.0-rc5-00008-gdf56e0f2f3ca #84 [ 419.949007] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 419.950035] Seguimiento de llamadas: [ 419.950384] [ 419.950676] dump_stack_lvl+0x57/0x78 [ 419.951212] ? kmem_cache_debug_flags+0xc/0x1d [ 419.953561] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.954231] kasan_report+0x89/0xb0 [ 419.954748] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.955367] hfsplus_read_wrapper+0x659/0xa0a [ 419.955948] ? __pfx_hfsplus_read_wrapper+0x10/0x10 [ 419.956618] ? do_raw_spin_unlock+0x59/0x1a9 [ 419.957214] ? _raw_spin_unlock+0x1a/0x2e [ 419.957772] hfsplus_fill_super+0x348/0x1590 [ 419.958355] ? hlock_class+0x4c/0x109 [ 419.958867] ? __pfx_hfsplus_fill_super+0x10/0x10 [ 419.959499] ? __pfx_string+0x10/0x10 [ 419.960006] ? lock_acquire+0x3e2/0x454 [ 419.960532] ? bdev_name.constprop.0+0xce/0x243 [ 419.961129] ? __pfx_bdev_name.constprop.0+0x10/0x10 [ 419.961799] ? puntero+0x3f0/0x62f [ 419.962277] ? __pfx_pointer+0x10/0x10 [ 419.962761] ? vsnprintf+0x6c4/0xfba [ 419.963178] ? __pfx_vsnprintf+0x10/0x10 [ 419.963621] ? setup_bdev_super+0x376/0x3b3 [ 419.964029] ? snprintf+0x9d/0xd2 [ 419.964344] ? __pfx_snprintf+0x10/0x10 [ 419.964675] ? lock_acquired+0x45c/0x5e9 [ 419.965016] ? set_blocksize+0x139/0x1c1 [ 419.965381] ? __pfx_hfsplus_fill_super+0x10/0x10 [ 419.966179] mount_bdev+0x12f/0x1bf [ 419.966512] ? __pfx_mount_bdev+0x10/0x10 [ 419.966886] ? vfs_parse_fs_string+0xce/0x111 [ 419.967293] ? __pfx_vfs_parse_fs_string+0x10/0x10 [ 419.967702] ? __pfx_hfsplus_mount+0x10/0x10 [ 419.968073] árbol_obtención_legado+0x104/0x178 [ 419.968414] árbol_obtención_vfs+0x86/0x296 [ 419.968751] montaje_ruta+0xba3/0xd0b [ 419.969157] ? __pfx_path_mount+0x10/0x10 [ 419.969594] ? kmem_cache_free+0x1e2/0x260 [ 419.970311] montaje_ruta+0x99/0xe0 [ 419.970630] ? __pfx_do_mount+0x10/0x10 [ 419.971008] __do_sys_mount+0x199/0x1c9 [ 419.971397] do_syscall_64+0xd0/0x135 [ 419.971761] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 419.972233] RIP: 0033:0x7c3cb812972e [ 419.972564] Código: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48 [ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 [ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e [ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: Arreglar la desreferencia de puntero NULL en object->file En la actualidad, object->file tiene el problema de desreferencia de puntero NULL en el modo ondemand. La causa raíz es que el fd asignado y el tiempo de vida de object->file son inconsistentes, y la invocación del espacio de usuario a anon_fd usa object->file. A continuación, se muestra el proceso que desencadena el problema: [write fd] [umount] cachefiles_ondemand_fd_write_iter fscache_cookie_state_machine cachefiles_withdraw_cookie if (!file) return -ENOBUFS cachefiles_clean_up_object cachefiles_unmark_inode_in_use fput(object->file) object->file = NULL // file ¡Desreferencia de puntero NULL! __cachefiles_write(..., file, ...) Solucione este problema agregando un recuento de referencia adicional al objeto->archivo antes de escribir/llseek, y disminuya después de que finalice.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg() kmalloc puede fallar, el valor de retorno puede ser NULL y provocará la desreferencia del puntero NULL. Agregue check NULL return of kmalloc in btc_fw_set_monreg().