Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau/dispnv04: corrige la desreferencia del puntero nulo en nv17_tv_get_hd_modes En nv17_tv_get_hd_modes(), el valor de retorno de drm_mode_duplicate() se asigna al modo, lo que conducirá a una posible desreferencia del puntero NULL en caso de falla de drm_mode_duplicate(). Lo mismo se aplica a drm_cvt_mode(). Agregue una marca para evitar la desreferencia del puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/gt: corrige un posible UAF mediante la revocación de los registros de valla. CI ha estado informando esporádicamente el siguiente problema provocado por igt@i915_selftest@live@hangcheck en ADL-P y máquinas similares. : <6> [414.049203] I915: ejecutando Intel_hangcheck_live_SelfTests/IGT_RESET_EVICT_FENCE ... <6> [414.068804] I915 0000: 00: 02.0: [DRM] GT0: GUC: CUBLICIDAD : [drm] GT0: GUC: SLPC habilitado <3> [414.070354] No se puede fijar la cerca con mosaicos en Y; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) ... <4>[ 609.603992] ------------[ cortar aquí ]- ----------- <2>[ 609.603995] ¡ERROR del kernel en drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Contaminado: GUW 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4 >[ 609.604008] Nombre del hardware: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 20/01/2023 <4>[ 609.604010] Cola de trabajo: i915 __i915_gem_free_work [i915] <4 >[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... <4>[ 609.604271] Seguimiento de llamadas: <4>[ 609.604273] ... <4>[ 609.604716] ct+0x2e9/ 0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] x2f/0xa0 [i915] <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440 process_scheduled_works+0x351/0x690... En el pasado, hubo fallas similares informado por CI de otras pruebas de IGT, observado en otras plataformas. Antes de confirmar 63baf4f3d587 ("drm/i915/gt: solo espere la actividad de la GPU antes de desvincular una valla GGTT"), i915_vma_revoke_fence() estaba esperando la inactividad de vma->active a través de fence_update(). Ese compromiso introdujo vma->fence->active para que fence_update() pudiera esperar selectivamente en ese en lugar de vma->active, ya que solo se necesitaba la inactividad de los registros de cerca. Pero luego, otra confirmación 0d86ee35097a ("drm/i915/gt: Hacer que la revocación de la valla sea inequívoca") reemplazó la llamada a fence_update() en i915_vma_revoke_fence() con solo fence_write(), y también agregó que GEM_BUG_ON(!i915_active_is_idle(&fence->active )) Al frente. No se proporcionó ninguna justificación sobre por qué podríamos esperar que vma->fence->active esté inactivo sin esperarlo primero. El problema puede deberse potencialmente a una carrera entre la revocación de registros de valla por un lado y la ejecución secuencial de devoluciones de llamadas de señales invocadas al completar una solicitud que las estaba usando por el otro, aún procesadas en paralelo a la revocación de esos registros de valla. Solucionelo esperando a que vma->fence->active esté inactivo en i915_vma_revoke_fence(). (cereza escogida del compromiso 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: evite usar el objeto nulo del framebuffer. En lugar de usar state->fb->obj[0] directamente, obtenga el objeto del framebuffer llamando a drm_gem_fb_get_obj() y devuelva el código de error. cuando el objeto es nulo para evitar el uso de un objeto nulo de framebuffer.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/fbdev-dma: solo configurar smem_start está habilitado por opción de módulo. Solo exporte la estructura fb_info.fix.smem_start si así lo requiere el usuario y la memoria no proviene de vmalloc( ). La configuración de struct fb_info.fix.smem_start interrumpe los sistemas donde la memoria DMA está respaldada por el espacio de direcciones vmalloc. A continuación se muestra un error de ejemplo. [3.536043] ------------[ cortar aquí ]------------ [ 3.540716] virt_to_phys usado para direcciones no lineales: 000000007fc4f540 (0xffff800086001000) [ 3.552628] ADVERTENCIA : CPU: 4 PID: 61 en arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x68/0x98 [ 3.565455] Módulos vinculados en: [ 3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 No contaminado 6.6 .23-06226-g4986cc3e1b75-dirty #250 [ 3.577310] Nombre de hardware: placa NXP i.MX95 19X19 (DT) [ 3.582452] Cola de trabajo: events_unbound deferred_probe_work_func [ 3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT- SSBS BTYPE=--) [ 3.595233] pc : __virt_to_phys+0x68/0x98 [ 3.599246] lr : __virt_to_phys+0x68/0x98 [ 3.603276] sp : ffff800083603990 [ 3.677939] Rastreo de llamadas: [ 3.68039 3] __virt_to_phys+0x68/0x98 [ 3.684067] drm_fbdev_dma_helper_fb_probe +0x138/0x238 [ 3.689214] __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0 [ 3.695385] drm_fb_helper_initial_config+0x4c/0x68 [ 3.700264] xe0 [ 3.705161] drm_client_register+0x60/0xb0 [ 3.709269] drm_fbdev_dma_setup+0x94/0x148 Además, se supone memoria DMA a por contiguo en el espacio de direcciones físicas, lo cual no está garantizado por vmalloc(). Resuelva esto verificando el indicador del módulo drm_leak_fbdev_smem cuando DRM asignó la instancia de la estructura fb_info. Luego, Fbdev-dma solo configura smem_start solo si es necesario (a través de FBINFO_HIDE_SMEM_START). También garantice que el framebuffer no esté ubicado en el espacio de direcciones vmalloc.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau/dispnv04: corrige la desreferencia del puntero null en nv17_tv_get_ld_modes En nv17_tv_get_ld_modes(), el valor de retorno de drm_mode_duplicate() se asigna al modo, lo que conducirá a una posible desreferencia del puntero NULL en caso de falla de drm_mode_duplicate(). Agregue una marca para evitar npd.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI/MSI: corrige UAF en msi_capability_init KFENCE informa el siguiente UAF: ERROR: KFENCE: lectura de uso después de liberación en __pci_enable_msi_range+0x2c0/0x488 Lectura de uso después de liberación en 0x0000000024629571 (en kfence-#12): __pci_enable_msi_range+0x2c0/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 kfence-#12: 0x0000000008614900-0x00000000e06c22 8d, tamaño=104, caché=kmalloc-128 asignado por la tarea 81 en la CPU 7 en 10.808142 s: __kmem_cache_alloc_node+0x1f0/0x2bc kmalloc_trace+0x44/0x138 msi_alloc_desc+0x3c/0x9c msi_domain_insert_msi_desc+0x30/0x78 msi_setup_msi_desc+0x13c/0x184 __pci_enable_msi_range+0 x258/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 liberado por la tarea 81 en la CPU 7 en 10.811436s: msi_domain_free_descs+0xd4/0x10c msi_domain_free_locked.part.0+0xc0/0x1d8 msi_domain_alloc_irqs_all_locked+0xb4/0xbc pci_msi_setup_msi_irqs+0x30/0x4c __pci_enable_msi_range+ 0x2a8/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 Asignación de descriptores realizada en: __pci_enable_msi_range msi_capability_init msi_setup_msi_desc msi_insert_msi_desc msi_domain_insert_msi_desc msi_alloc_desc ... Liberado en caso de fallo en __msi_domain_alloc_locked() __pci_enable_msi_range msi_capability_init pci_msi_setup_msi_irqs msi_domain_alloc_irqs_all_locked msi_domain_alloc_locked __msi_ domain_alloc_locked => falla msi_domain_free_locked... Ese error se propaga nuevamente a pci_msi_setup_msi_irqs() en msi_capability_init() que accede al descriptor para desenmascarar en la salida de error camino. Soréguelo copiando el descriptor y usando la copia para la operación de desenmascarar la ruta de salida del error. [tglx: registro de cambios masajeado]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: atm: cxacru: corrige la comprobación de endpoints en cxacru_bind() Syzbot todavía informa de un problema bastante antiguo [1] que se produce debido a una comprobación incompleta de los endpoints USB actuales. Como tal, se pueden usar tipos de endpoints incorrectos en la etapa de envío de urb, lo que a su vez activa una advertencia en usb_submit_urb(). Solucione el problema verificando que los tipos de endpoints requeridos estén presentes tanto para los endpoints de entrada como para los de salida, teniendo en cuenta el tipo de endpoint cmd. Desafortunadamente, este parche no ha sido probado en hardware real. [1] Informe Syzbot: usb 1-1: BOGUS urb xfer, tubería 1! = tipo 3 ADVERTENCIA: CPU: 0 PID: 8667 en drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/ core/urb.c:502 Módulos vinculados en: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01 /01/2011 Cola de trabajo: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Seguimiento de llamadas: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+ 0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [en línea] Actually_probe+0x23c/0xcd0 drivers/ base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv +0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/ core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver. c:293

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: libata-core: corrige la desreferencia del puntero nulo en caso de error Si la llamada ata_port_alloc() en ata_host_alloc() falla, se llamará ata_host_release(). Sin embargo, el código en ata_host_release() intenta liberar incondicionalmente a los miembros de la estructura ata_port, lo que puede provocar lo siguiente: ERROR: no se puede manejar el error de página para la dirección: 0000000000003990 PGD 0 P4D 0 Ups: Ups: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 PID: 594 Comunicaciones: (udev-worker) No contaminado 6.10.0-rc5 #44 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 01/04/2014 RIP : 0010:ata_host_release.cold+0x2f/0x6e [libata] Código: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41 RSP: 0018:ffffc90000ebb968 00010246 RAX : 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0 RBP: ffff888 10fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68 R10: ffffc90000ebb738 R11: 73692033203a746e R12: 000000000000004 R13: 00000000 R14: 0000000000000011 R15: 0000000000000006 FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000003990 CR3: 00000001122a200 0 CR4: 0000000000750ef0 PKRU: 55555554 Seguimiento de llamadas: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0? exc_page_fault+0x7e/0x180? asm_exc_page_fault+0x26/0x30? ata_host_release.cold+0x2f/0x6e [libata]? ata_host_release.cold+0x2f/0x6e [libata] release_nodes+0x35/0xb0 devres_release_group+0x113/0x140 ata_host_alloc+0xed/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 ] No acceder a los miembros de la estructura ata_port incondicionalmente.

El control de acceso incorrecto en el altavoz inteligente nano Himalaya Xiaoya rom_version 1.6.96 permite que un atacante remoto tenga un impacto no especificado.

Vulnerabilidad de desbordamiento de búfer en host-host NEUQ_board v.1.0 permite que un atacante remoto provoque una denegación de servicio a través del componente password.h.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: can: j1939: manejo de errores mejorado para mensajes RTS recibidos estrechamente en xtp_rx_rts_session_new Este parche mejora el manejo de errores en escenarios con mensajes RTS (Solicitud de envío) que llegan cerca. Reemplaza los rastreos WARN_ON_ONCE menos informativos con un nuevo método de manejo de errores. Esto proporciona mensajes de error más claros y permite la finalización anticipada de sesiones problemáticas. Anteriormente, las sesiones sólo se publicaban al final de j1939_xtp_rx_rts(). Potencialmente, esto podría reproducirse con algo como: testj1939 -r vcan0:0x80 & while true; hacer # enviar primero RTS cansend vcan0 18EC8090#1014000303002301; # enviar segundo RTS cansend vcan0 18EC8090#1014000303002301; # enviar cancelar cansend vcan0 18EC8090#ff00000000002301; hecho

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: corrija netfs_page_mkwrite() para verificar que folio->mapping sea válido. Corrija netfs_page_mkwrite() para verificar que folio->mapping sea válido una vez que haya tomado el bloqueo de folio (como filemap_page_mkwrite( ) hace). Sin esto, generic/247 ocasionalmente falla con algo como lo siguiente: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente RIP: 0010:trace_event_raw_event_netfs_folio +0x61/0xc0... Seguimiento de llamadas: ? __die_body+0x1a/0x60 ? page_fault_oops+0x6e/0xa0? exc_page_fault+0xc2/0xe0? asm_exc_page_fault+0x22/0x30? trace_event_raw_event_netfs_folio+0x61/0xc0 trace_netfs_folio+0x39/0x40 netfs_page_mkwrite+0x14c/0x1d0 do_page_mkwrite+0x50/0x90 do_pte_missing+0x184/0x200 __handle_mm_fault+0x42d/0x500 _fault+0x121/0x1f0 do_user_addr_fault+0x23e/0x3c0 exc_page_fault+0xc2/0xe0 asm_exc_page_fault+0x22/0x30 Esto se debe a que invalidate_inode_pages2_range() emitido al final de la escritura DIO interfiere con las escrituras mmap.