Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ibmvfc: Eliminar BUG_ON en el caso de un grupo de eventos vacío. En la práctica, el controlador nunca debe enviar más comandos de los asignados al grupo de eventos de una cola. En el improbable caso de que esto suceda, el código afirma un BUG_ON, y en el caso de que el kernel no esté configurado para fallar en caso de pánico, devuelve un puntero de evento basura de la lista de eventos vacía, lo que hace que las cosas vayan en espiral a partir de ahí. Este BUG_ON es un artefacto histórico del controlador ibmvfc que se actualizó por primera vez, y ahora es bien sabido que el uso de BUG_ON es una mala práctica, excepto en el escenario más irrecuperable. No hay nada en este escenario que impida al conductor recuperarse y continuar. Elimine el BUG_ON en cuestión de ibmvfc_get_event() y devuelva un puntero NULL en el caso de un grupo de eventos vacío. Actualice todos los sitios de llamadas a ibmvfc_get_event() para comprobar si hay un puntero NULL y realizar la acción de recuperación o error adecuada.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: pcrypt - Reparar hungtask para PADATA_RESET. Encontramos un error de hungtask en test_aead_vec_cfg de la siguiente manera: INFORMACIÓN: tarea cryptomgr_test:391009 bloqueada durante más de 120 segundos. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. Seguimiento de llamadas: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 Schedule+0xd8/0x1b4 Schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_ve c_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+ 0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 kernel panic - no syncing: hung_task: tareas bloqueadas para el error for_completion (&esperar->finalización) en test_aead_vec_cfg. En caso normal, se llamará aead_request_complete() en pcrypt_aead_serial y el error de retorno es 0 para padata_do_parallel. Pero, cuando pinst->flags es PADATA_RESET, el error de retorno es -EBUSY para padata_do_parallel y no llamará a aead_request_complete(). Por lo tanto, test_aead_vec_cfg se colgará en wait_for_completion(&wait->completion), lo que provocará que se cuelgue la tarea. El problema viene de la siguiente manera: (padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | si (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return err Para resolver el problema, reemplazamos el retorno err -EBUSY con -EAGAIN, lo que significa que los datos_paralelos están cambiando y la persona que llama debe llamarlo nuevamente. v3: elimine el reintento y simplemente cambie el error de devolución. v2: introduce padata_try_do_parallel() en pcrypt_aead_encrypt y pcrypt_aead_decrypt para resolver la tarea colgada.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: soluciona una posible desreferencia del puntero null. Amdgpu_ras_get_context puede devolver NULL si el dispositivo no admite la función ras, así que agregue la verificación antes de usarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu/vkms: soluciona una posible desreferencia del puntero null. En amdgpu_vkms_conn_get_modes(), el valor de retorno de drm_cvt_mode() se asigna al modo, lo que provocará una desreferencia del puntero NULL en falla de drm_cvt_mode(). Agregue una marca para evitar la desreferencia del puntero null.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdkfd: solucionó el problema de desplazamiento fuera de límites [567.613292] el exponente de desplazamiento 255 es demasiado grande para el tipo de 64 bits 'long unsigned int' [567.614498] CPU: 5 PID : 238 Comm: kworker/5:1 Tainted: G OE 6.2.0-34-generic #34~22.04.1-Ubuntu [ 567.614502] Nombre de hardware: AMD Splinter/Splinter-RPL, BIOS WS43927N_871 25/09/2023 [ 567.614504 ] Cola de trabajo: eventos send_exception_work_handler [amdgpu] [ 567.614748] Seguimiento de llamadas: [ 567.614750] [ 567.614753] dump_stack_lvl+0x48/0x70 [ 567.614761] dump_stack+0x10/0x20 [ 567.6147 63] __ubsan_handle_shift_out_of_bounds+0x156/0x310 [567.614769]? srso_alias_return_thunk+0x5/0x7f [567.614773]? update_sd_lb_stats.constprop.0+0xf2/0x3c0 [567.614780] svm_range_split_by_granularity.cold+0x2b/0x34 [amdgpu] [567.615047]? srso_alias_return_thunk+0x5/0x7f [ 567.615052] svm_migrate_to_ram+0x185/0x4d0 [amdgpu] [ 567.615286] do_swap_page+0x7b6/0xa30 [ 567.615291] ? srso_alias_return_thunk+0x5/0x7f [567.615294]? __free_pages+0x119/0x130 [ 567.615299] handle_pte_fault+0x227/0x280 [ 567.615303] __handle_mm_fault+0x3c0/0x720 [ 567.615311] handle_mm_fault+0x119/0x330 [ 567.61 5314] ? lock_mm_and_find_vma+0x44/0x250 [ 567.615318] do_user_addr_fault+0x1a9/0x640 [ 567.615323] exc_page_fault+0x81/0x1b0 [ 567.615328] asm_exc_page_fault+0x27/0x30 [ 567.615332] RIP: 0010:__get_user_8+0x1c/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrige un acceso de puntero null cuando el puntero smc_rreg es NULL. En ciertos tipos de chips, como VEGA20, la lectura del archivo amdgpu_regs_smc podría resultar en un acceso anormal de puntero null cuando el puntero smc_rreg es NULL. A continuación se detallan los pasos para reproducir este problema y el registro de excepciones correspondiente: 1. Navegue hasta el directorio: /sys/kernel/debug/dri/0 2. Ejecute el comando: cat amdgpu_regs_smc 3. Registro de excepciones:: [4005007.702554] BUG: kernel Desreferencia de puntero NULL, dirección: 0000000000000000 [4005007.702562] #PF: búsqueda de instrucciones del supervisor en modo kernel [4005007.702567] #PF: código_error(0x0010) - página no presente [4005007.702570] PGD 0 P4D 0 [4005007. 702576] Ups: 0010 [#1 ] SMP NOPTI [4005007.702581] CPU: 4 PID: 62563 Comm: Cat Tainted: G Oe 5.15.0-43-Generic #46-Ubunt U [4005007.702590] RIP: 0010: 0x0 [4005007.702598] Código: Incedente de acceso a acceso a acceso a acceso a acceso a acceso a acceso a acceso a acceso a acceso a acceso a la operación. QEPD 0xffffffffffffffd6. [4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206 [4005007.702605] RAX: 00000000000000000 RBX: 0000000000000000 RCX: e68 [4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000 [4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000 R09: ffff994060c07980 [4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000 [4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 007f5e06753000 [4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000 [4005007.702626] CS: 0010 DS: 0000ES: 0000 CR0: 0000000080050033 [4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0 [4005007.702633] Seguimiento de llamadas: [4005007.7 02636] [4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu] [4005007.703002] full_proxy_read+0x5c/0x80 [4005007.703011] vfs_read+0x9f/0x1a0 [4005007.703019] ksys_read+0x67/0xe0 [4005007.703023] __x64_sys_read+0x19/0x20 [4005007.703028] do_syscall_64+0x5c/0xc0 [40 05007.703034] ? do_user_addr_fault+0x1e3/0x670 [4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0 [4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20 [4005007.703052] ? irqentry_exit+0x19/0x30 [4005007.703057] ? exc_page_fault+0x89/0x160 [4005007.703062] ? asm_exc_page_fault+0x8/0x30 [4005007.703068] Entry_SYSCALL_64_after_hwframe+0x44/0xae [4005007.703075] RIP: 0033:0x7f5e07672992 [4005007.703079] Código: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24 [4005007.70 3083]RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992 [4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003 [4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 007f5e06752010 [4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000 [4005007.703099] R13: 000000000000003 R14: 0000000000020000 R15: 0000000000020000 [40050 07.703105] [4005007.703107] Módulos vinculados en: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) _helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca [4005007.703184] CR2: 0000000000000000 [4005007.703188] ---[ es ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd: corrige el índice de matriz UBSAN fuera de límites para SMU7. Para estructuras pptable que usan tamaños de matriz flexibles, use matrices flexibles.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd: corrige el índice de matriz UBSAN fuera de límites para Polaris y Tonga. Para estructuras pptable que usan tamaños de matriz flexibles, use matrices flexibles.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm_lease.c: copia la matriz de usuarios de forma segura. Actualmente, no hay verificación de desbordamiento con memdup_user(). Utilice la nueva función memdup_array_user() en lugar de memdup_user() para duplicar la matriz de espacio de usuario de forma segura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd: comprueba el número de niveles de enlace cuando se actualiza el parámetro pcie. En el entorno SR-IOV, el valor de pcie_table->num_of_link_levels será 0, y num_of_levels - 1 provocará un índice de matriz fuera de los límites.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: térmica: intel: powerclamp: corrige la falta de coincidencia en la función get para max_idle KASAN informó esto [444.853098] BUG: KASAN: global-fuera de los límites en param_get_int+0x77/0x90 [444.853111 ] Lectura de tamaño 4 en addr ffffffffc16c9220 por tarea cat/2105... [444.853442] La dirección con errores pertenece a la variable: [444.853443] max_idle+0x0/0xffffffffffffffcde0 [intel_powerclamp] Hay una discrepancia entre param_get_int y la definición de max_idle . Reemplazar param_get_int con param_get_byte resuelve este problema.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: vhost-vdpa: corrige el use after free en vhost_vdpa_probe(). El put_device() llama a vhost_vdpa_release_dev() que llama a ida_simple_remove() y libera "v". Entonces esta llamada a ida_simple_remove() es un use after free y double free.