Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: proceso: corrección de fuga de información del kernel. El array s[12] de thread_struct puede contener contenido aleatorio de memoria del kernel, que podría filtrarse al espacio de usuario. Esto representa una vulnerabilidad de seguridad. Para solucionarlo, borre la matriz s[12] de thread_struct al bifurcar. En el caso de kthread, es recomendable borrar también la matriz s[12].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrigen fugas de memoria en __check_func_call kmemleak informa de este problema: objeto sin referencia 0xffff88817139d000 (tamaño 2048): comm "test_progs", pid 33246, jiffies 4307381979 (edad 45851.820s) volcado hexadecimal (primeros 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000045f075f0>] kmalloc_trace+0x27/0xa0 [<0000000098b7c90a>] __check_func_call+0x316/0x1230 [<00000000b4c3c403>] check_helper_call+0x172e/0x4700 [<00000000aa3875b7>] do_check+0x21d8/0x45e0 [<000000001147357b>] do_check_common+0x767/0xaf0 [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0 [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940 [<0000000007f765c0>] __sys_bpf+0xd2c/0x3650 [<00000000839815d6>] __x64_sys_bpf+0x75/0xc0 [<00000000946ee250>] do_syscall_64+0x3b/0x90 [<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd El caso raíz aquí es: En la función prepare_func_exit(), el llamado no se libera en el escenario anormal después de "state->curframe--;". Para solucionarlo, mueva "state->curframe--;" al final de la función, justo cuando liberamos al destinatario y restablecemos el puntero frame[] a NULL, como sugirió Andrii. Además, la función __check_func_call() presenta un problema similar. En el escenario anormal anterior a "state->curframe++;", el destinatario también debería ser liberado por free_func_state().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: scsi_transport_sas: Corregir error de manejo en sas_phy_add() Si transport_add_device() falla en sas_phy_add(), el kernel se bloqueará al intentar eliminar el dispositivo en transport_remove_device() llamado desde sas_remove_host(). No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000108 CPU: 61 PID: 42829 Comm: rmmod Kdump: cargado Tainted: GW 6.1.0-rc1+ #173 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x54/0x3d0 lr : device_del+0x37c/0x3d0 Rastreo de llamadas: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_phy_delete+0x30/0x60 [scsi_transport_sas] do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x40/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] hisi_sas_remove+0x40/0x68 [hisi_sas_main] hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw] platform_remove+0x2c/0x60 Fix this by checking and handling return value of transport_add_device() in sas_phy_add().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, test_run: Se solucionó un problema de alineación en bpf_prog_test_run_skb(). Se detectó un problema en syzkaller debido a un fallo de alineación de aarch64 si KFENCE estaba habilitado. Cuando el tamaño del programa bpf del usuario es un número impar, como 399, 407, etc., se produce un acceso no alineado a la estructura skb_shared_info. Como se ve a continuación: ERROR: KFENCE: lectura de use-after-free en __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Lectura de use-after-free en 0xffff6254fffac077 (en kfence-#213): __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [en línea] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [en línea] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [en línea] atomic_inc include/asm-generic/atomic-instrumented.h:241 [en línea] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [en línea] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [en línea] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [en línea] __do_sys_bpf kernel/bpf/syscall.c:4441 [en línea] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, tamaño=407, caché=kmalloc-512 asignado por la tarea 15074 en la CPU 0 a las 1342.585390 s: kmalloc include/linux/slab.h:568 [en línea] kzalloc include/linux/slab.h:675 [en línea] bpf_test_init.isra.0+0xac/0x290 Para corregir el problema, ajustamos @size de modo que (@size + @hearoom) sea un múltiplo de SMP_CACHE_BYTES. Así nos aseguramos de que la estructura skb_shared_info esté alineada con una línea de caché.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: núcleo: Se corrige el use-after-free en snd_soc_exit() KASAN informa un use-after-free: ERROR: KASAN: use-after-free en device_del+0xb5b/0xc60 Lectura de tamaño 8 en la dirección ffff888008655050 por la tarea rmmod/387 CPU: 2 PID: 387 Comm: rmmod Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996) Rastreo de llamadas: dump_stack_lvl+0x79/0x9a print_report+0x17f/0x47b kasan_report+0xbb/0xf0 device_del+0xb5b/0xc60 platform_device_del.part.0+0x24/0x200 platform_device_unregister+0x2e/0x40 snd_soc_exit+0xa/0x22 [snd_soc_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... It's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail, but its ret is ignored, which makes soc_dummy_dev unregistered twice. snd_soc_init() snd_soc_util_init() platform_device_register_simple(soc_dummy_dev) platform_driver_register() # fail platform_device_unregister(soc_dummy_dev) platform_driver_register() # success ... snd_soc_exit() snd_soc_util_exit() # soc_dummy_dev will be unregistered for second time To fix it, handle error and stop snd_soc_init() when util_init() fail. Also clean debugfs when util_init() or driver_register() fail.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Migrar en la CPU con fallos de página al usar la función mm actual. El método "migrate_vma_setup" muestra la siguiente advertencia porque no se mantiene el bloqueo mmap_lock de otro proceso. Deberíamos usar la función "vmf->vma->vm_mm" actual, ya que el llamador ya mantiene el bloqueo mmap actual dentro del controlador de fallos de página de la CPU. ADVERTENCIA: CPU: 10 PID: 3054 en include/linux/mmap_lock.h:155 Seguimiento de llamadas find_vma: walk_page_range+0x76/0x150 migrate_vma_setup+0x18a/0x640 svm_migrate_vram_to_ram+0x245/0xa10 [amdgpu] svm_migrate_to_ram+0x36f/0x470 [amdgpu] do_swap_page+0xcfe/0xec0 __handle_mm_fault+0x96b/0x15e0 handle_mm_fault+0x13f/0x3e0 do_user_addr_fault+0x1e7/0x690

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: dev: fix skb drop check. En el commit a6d190f8c767 ("can: skb: drop tx skb if in listen only mode"), el elemento priv->ctrlmode se lee incluso en interfaces CAN virtuales que no crean la estructura can_priv al inicio. Esta lectura fuera de los límites puede provocar la pérdida de tramas CAN en interfaces CAN virtuales como vcan y vxcan. Este parche revierte principalmente la confirmación original y añade un nuevo asistente para los controladores de interfaz CAN que proporciona la información necesaria en la estructura can_priv. [mkl: parchear también pch_can]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: siox: Se corrige una posible fuga de memoria en siox_device_add(). Si device_register() devuelve un error en siox_device_add(), se debe liberar el nombre asignado por dev_set_name(). Como se indica en el comentario de device_register(), se debe usar put_device() para liberar la referencia en la ruta de error. Para solucionar esto, se debe llamar a put_device(); de esta manera, se puede liberar el nombre en kobject_cleanup() y sdevice se libera en siox_device_release(); configúrelo como nulo en la ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: borrar out_curr si se eliminan todos los fragmentos del mensaje actual. Zhen Chen informó de un fallo: corrupción de list_del, ffffa035ddf01c18->next es NULL ADVERTENCIA: CPU: 1 PID: 250682 en lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0 RIP: 0010:__list_del_entry_valid+0x59/0xe0 Rastreo de llamadas: sctp_sched_dequeue_common+0x17/0x70 [sctp] sctp_sched_fcfs_dequeue+0x37/0x50 [sctp] sctp_outq_flush_data+0x85/0x360 [sctp] sctp_outq_uncork+0x77/0xa0 [sctp] sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp] sctp_side_effects+0x37/0xe0 [sctp] sctp_do_sm+0xd0/0x230 [sctp] sctp_primitive_SEND+0x2f/0x40 [sctp] sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp] sctp_sendmsg+0x3d5/0x440 [sctp] sock_sendmsg+0x5b/0x70 y en sctp_sched_fcfs_dequeue() quitó de la cola un fragmento del flujo out_curr outq mientras este outq estaba vacío. Normalmente, stream->out_curr debe establecerse en NULL una vez que se hayan desencolado todos los fragmentos del mensaje actual, como se puede ver en sctp_sched_dequeue_done(). Sin embargo, en sctp_prsctp_prune_unsent(), dado que no es una desencola adecuada, no se llama a sctp_sched_dequeue_done() para realizar esto. Este parche soluciona este problema simplemente estableciendo out_curr en NULL cuando se desencola el último fragmento del mensaje actual del flujo out_curr en sctp_prsctp_prune_unsent().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: imx: Agregar el gancho .thaw_noirq faltante. La siguiente advertencia se ve con una instancia UART que no es de consola cuando el sistema hiberna. [ 37.371969] ------------[ cortar aquí ]------------ [ 37.376599] uart3_root_clk ya está deshabilitado [ 37.380810] ADVERTENCIA: CPU: 0 PID: 296 en drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0 ... [ 37.506986] Rastreo de llamadas: [ 37.509432] clk_core_disable+0xa4/0xb0 [ 37.513270] clk_disable+0x34/0x50 [ 37.516672] imx_uart_thaw+0x38/0x5c [ 37.520250] platform_pm_thaw+0x30/0x6c [ 37.524089] dpm_run_callback.constprop.0+0x3c/0xd4 [ 37.528972] device_resume+0x7c/0x160 [ 37.532633] dpm_resume+0xe8/0x230 [ 37.536036] hibernation_snapshot+0x288/0x430 [ 37.540397] hibernate+0x10c/0x2e0 [ 37.543798] state_store+0xc4/0xd0 [ 37.547203] kobj_attr_store+0x1c/0x30 [ 37.550953] sysfs_kf_write+0x48/0x60 [ 37.554619] kernfs_fop_write_iter+0x118/0x1ac [ 37.559063] new_sync_write+0xe8/0x184 [ 37.562812] vfs_write+0x230/0x290 [ 37.566214] ksys_write+0x68/0xf4 [ 37.569529] __arm64_sys_write+0x20/0x2c [ 37.573452] invoke_syscall.constprop.0+0x50/0xf0 [ 37.578156] do_el0_svc+0x11c/0x150 [ 37.581648] el0_svc+0x30/0x140 [ 37.584792] el0t_64_sync_handler+0xe8/0xf0 [ 37.588976] el0t_64_sync+0x1a0/0x1a4 [ 37.592639] ---[ end trace 56e22eec54676d75 ] Al hibernar, el núcleo pm llama a los ganchos relacionados en secuencia como: .freeze .freeze_noirq .thaw_noirq .thaw Si el gancho .thaw_noirq está ausente, el reloj se deshabilitará en una llamada desequilibrada que genera la advertencia anterior. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_thaw clk_disable_unprepare() Agregar el gancho .thaw_noirq faltante como imx_uart_resume_noirq() corregirá la secuencia de llamada como se muestra a continuación y, por lo tanto, solucionará la advertencia. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_resume_noirq() clk_enable() imx_uart_thaw clk_disable_unprepare()

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: devicetree: corrección de la desreferencia de puntero nulo en pinctrl_dt_to_map Aquí está el informe de ERROR de KASAN sobre la desreferencia de puntero nulo: ERROR: KASAN: null-ptr-deref en strcmp+0x2e/0x50 Lectura de tamaño 1 en la dirección 0000000000000000 por la tarea python3/2640 Rastreo de llamadas: strcmp __of_find_property of_find_property pinctrl_dt_to_map kasprintf() devolvería un puntero NULL cuando kmalloc() no pudiera asignar. Por lo tanto, devuelve directamente ENOMEM, si kasprintf() devuelve un puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: inicializar la información de zona del dispositivo para la propagación. Al propagar en un sistema de archivos con zonas, es necesario inicializar la estructura btrfs_zoned_device_info de cada dispositivo; de lo contrario, al montar el sistema de archivos se producirá una desreferencia de puntero nulo. Esto fue descubierto por el caso de prueba btrfs/163 de fstests.