Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: evitar el acceso a skb en nf_stolen Cuando el veredicto es NF_STOLEN, es posible que se haya liberado el skb. Cuando el rastreo está habilitado, esto puede dar como resultado un use-after-free: 1. acceso a skb->nf_trace 2. acceso a skb->mark 3. cálculo del identificador de rastreo 4. volcado de el payload del paquete Para evitar 1, mantenga una copia en caché de skb->nf_trace en la estructura de estado de rastreo. Actualice esta copia siempre que el veredicto sea != STOLEN. Evite 2 omitiendo el acceso a skb->mark si el veredicto es STOLEN. 3 se evita precalculando el identificador de rastreo. Solo vuelque el paquete cuando el veredicto no sea "STOLEN".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/xive/spapr: tamaño de asignación de mapa de bits correcto kasan detecta acceso más allá del final de la asignación xibm->bitmap: ERROR: KASAN: slab-out-of-bounds en _find_first_zero_bit+0x40/0x140 Lectura de tamaño 8 en la dirección c00000001d1d0118 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace: [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0 __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc esto sucede porque la asignación utiliza la unidad incorrecta (bits) cuando debería pasar (BITS_TO_LONGS(count) * sizeof(long)) o equivalente. Con una pequeña cantidad de bits, el objeto asignado puede ser más pequeño que sizeof(long), lo que genera accesos no válidos. Utilice bitmap_zalloc() para asignar e inicializar el mapa de bits de irq, junto con bitmap_free() para mantener la coherencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net:atlantic: eliminar aq_nic_deinit() cuando se ha llamado a la función aq_nic_deinit() durante la suspensión, por lo que no tenemos que llamarla nuevamente al reanudar. En realidad, llamarla nuevamente genera otro problema de bloqueo al reanudar desde S3. Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992345] Call Trace: Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992346] Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992348] aq_nic_deinit+0xb4/0xd0 [atlantic] Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992356] aq_pm_thaw+0x7f/0x100 [atlantic] Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992362] pci_pm_resume+0x5c/0x90 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992366] ? pci_pm_thaw+0x80/0x80 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992368] dpm_run_callback+0x4e/0x120 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992371] device_resume+0xad/0x200 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992373] async_resume+0x1e/0x40 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992374] async_run_entry_fn+0x33/0x120 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992377] process_one_work+0x220/0x3c0 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992380] worker_thread+0x4d/0x3f0 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992382] ? process_one_work+0x3c0/0x3c0 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992384] kthread+0x12a/0x150 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992386] ? set_kthread_struct+0x40/0x40 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992387] ret_from_fork+0x22/0x30 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992391] Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992392] ---[ end trace 1ec8c79604ed5e0d ]--- Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992394] PM: dpm_run_callback(): pci_pm_resume+0x0/0x90 returns -110 Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992397] atlantic 0000:02:00.0: PM: failed to resume async: error -110

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sfc: corregir pánico del kernel al crear VF Al crear VF, puede ocurrir un pánico del kernel al llamar a efx_ef10_try_update_nic_stats_vf. Al liberar un búfer coherente DMA, a veces, no sé en qué circunstancias específicas, tiene que desasignar la memoria con vunmap. No está permitido hacer eso en el contexto de IRQ o con BH deshabilitado. De lo contrario, llegamos a esta línea en vunmap, lo que provoca el bloqueo: BUG_ON(in_interrupt()); Este parche vuelve a habilitar BH para liberar el búfer. Mensajes de registro cuando se detecta el error: kernel BUG en mm/vmalloc.c:2727! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 1462 Comm: NetworkManager Kdump: loaded Tainted: G I --------- --- 5.14.0-119.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020 RIP: 0010:vunmap+0x2e/0x30 ...skip... Call Trace: __iommu_dma_free+0x96/0x100 efx_nic_free_buffer+0x2b/0x40 [sfc] efx_ef10_try_update_nic_stats_vf+0x14a/0x1c0 [sfc] efx_ef10_update_stats_vf+0x18/0x40 [sfc] efx_start_all+0x15e/0x1d0 [sfc] efx_net_open+0x5a/0xe0 [sfc] __dev_open+0xe7/0x1a0 __dev_change_flags+0x1d7/0x240 dev_change_flags+0x21/0x60 ...skip...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sfc: se corrige el use-after-free al deshabilitar sriov. El use-after-free es detectado por kfence al deshabilitar sriov. Lo que se leyó después de ser liberado fue vf->pci_dev: se liberó de pci_disable_sriov y luego se leyó en efx_ef10_sriov_free_vf_vports, llamado desde efx_ef10_sriov_free_vf_vswitching. Establezca el puntero en NULL en el momento de la liberación para no intentar leerlo más tarde. Registro del reproductor y dmesg (tenga en cuenta que kfence no lo detecta cada vez): $ echo 1 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs $ echo 0 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224): efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] efx_ef10_pci_sriov_disable+0x38/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k allocated by task 6771 on cpu 10 at 3137.860196s: pci_alloc_dev+0x21/0x60 pci_iov_add_virtfn+0x2a2/0x320 sriov_enable+0x212/0x3e0 efx_ef10_sriov_configure+0x67/0x80 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xba/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae freed by task 6771 on cpu 12 at 3170.991309s: device_release+0x34/0x90 kobject_cleanup+0x3a/0x130 pci_iov_remove_virtfn+0xd9/0x120 sriov_disable+0x30/0xe0 efx_ef10_pci_sriov_disable+0x57/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igc: Restablecer la lógica IGC_REMOVED e implementarla correctamente La versión fusionada inicialmente del código del controlador igc (a través de el commit 146740f9abc4, "igc: Agregar soporte para PF") contenía las siguientes comprobaciones IGC_REMOVED checks in the igc_rd32/wr32() MMIO accessors: u32 igc_rd32(struct igc_hw *hw, u32 reg) { u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr); u32 value = 0; if (IGC_REMOVED(hw_addr)) return ~value; value = readl(&hw_addr[reg]); /* reads should not return all F's */ if (!(~value) && (!reg || !(~readl(hw_addr)))) hw->hw_addr = NULL; return value; } And: #define wr32(reg, val) \ do { \ u8 __iomem *hw_addr = READ_ONCE((hw)->hw_addr); \ if (!IGC_REMOVED(hw_addr)) \ writel((val), &hw_addr[(reg)]); \ } while (0) Por ejemplo, igb tiene verificaciones similares en sus accesores MMIO y tiene una macro similar E1000_REMOVED, que se implementa de la siguiente manera: #define E1000_REMOVED(h) Unlikely(!(h)) Estas verificaciones sirven para detectar y tomar nota de un retorno de lectura MMIO 0xffffffff del dispositivo, que puede ser causado por una falla en el enlace PCIe o algún otro tipo de error de bus PCI, y para evitar realizar lecturas y escrituras MMIO desde ese punto en adelante. Sin embargo, la macro IGC_REMOVED no se implementó originalmente: #ifndef IGC_REMOVED #define IGC_REMOVED(a) (0) #endif /* IGC_REMOVED */ Esto provocó que la lógica IGC_REMOVED se eliminara por completo en una confirmación posterior (confirmación 3c215fb18e70, "igc: eliminar la función IGC_REMOVED"), con el fundamento de que dichas comprobaciones solo son importantes para la virtualización y que igc no admite la virtualización, pero un dispositivo PCIe puede desconectarse incluso sin que se utilice la virtualización y, sin las comprobaciones adecuadas, un error de bus PCIe que afecte a un adaptador igc provocará varias desreferencias de puntero NULL, ya que el primer acceso después del error establecerá hw->hw_addr en NULL, y los accesos posteriores desreferenciarán ciegamente este puntero ahora NULL. Este parche restablece las comprobaciones IGC_REMOVED en igc_rd32/wr32() e implementa IGC_REMOVED de la forma en que se hace para igb, comprobando el caso improbable() de que hw_addr sea NULL. Este cambio evita los errores que se observan cuando se produce una falla en el enlace PCIe en un adaptador igc.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/irdma: Arreglar suspensión desde contexto no válido ERROR Tomar qos_mutex para procesar los QP de RoCEv2 en eventos netdev provoca un splat del kernel. Solucione esto eliminando la gestión de RoCEv2 en irdma_cm_teardown_connections que usa el mutex. Esta gestión solo es necesario para que iWARP evite que se establezcan conexiones mientras el enlace está inactivo o que las conexiones permanezcan funcionales después de que se elimine la dirección IP. ERROR: función de suspensión llamada desde un contexto no válido en kernel/locking/mutex. Seguimiento de llamadas: kernel: dump_stack+0x66/0x90 kernel: ___might_sleep.cold.92+0x8d/0x9a kernel: mutex_lock+0x1c/0x40 kernel: irdma_cm_teardown_connections+0x28e/0x4d0 [irdma] kernel: ? check_preempt_curr+0x7a/0x90 kernel: ? select_idle_sibling+0x22/0x3c0 kernel: ? select_task_rq_fair+0x94c/0xc90 kernel: ? irdma_exec_cqp_cmd+0xc27/0x17c0 [irdma] kernel: ? __wake_up_common+0x7a/0x190 kernel: irdma_if_notify+0x3cc/0x450 [irdma] kernel: ? sched_clock_cpu+0xc/0xb0 kernel: irdma_inet6addr_event+0xc6/0x150 [irdma]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf_event_set_output() and perf_mmap_close() Yang Jihing reported a race between perf_event_set_output() and perf_mmap_close(): CPU1 CPU2 perf_mmap_close(e2) if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0 detach_rest = true ioctl(e1, IOC_SET_OUTPUT, e2) perf_event_set_output(e1, e2) ... list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry) ring_buffer_attach(e, NULL); // e1 isn't yet added and // therefore not detached ring_buffer_attach(e1, e2->rb) list_add_rcu(&e1->rb_entry, &e2->rb->event_list) After this; e1 is attached to an unmapped rb and a subsequent perf_mmap() will loop forever more: again: mutex_lock(&e->mmap_mutex); if (event->rb) { ... if (!atomic_inc_not_zero(&e->rb->mmap_count)) { ... mutex_unlock(&e->mmap_mutex); goto again; } } The loop in perf_mmap_close() holds e2->mmap_mutex, while the attach in perf_event_set_output() holds e1->mmap_mutex. Como tal, no hay serialización para evitar esta ejecución. Cambie perf_event_set_output() para que acepte tanto e1->mmap_mutex como e2->mmap_mutex para aliviar ese problema. Además, haga que el bucle en perf_mmap() desconecte el rb directamente, esto evita tener que esperar a que perf_mmap_close() concurrente lo haga para avanzar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: ralink: Verificar el retorno nulo de devm_kcalloc Debido a la posible falla de la asignación, data->domains podría ser un puntero NULL y provocará la desreferencia del puntero NULL más adelante. Por lo tanto, podría ser mejor verificarlo y devolver directamente -ENOMEM sin liberar los datos manualmente si falla, porque el comentario de devm_kmalloc() dice "La memoria asignada con esta función se libera automáticamente al desconectar el controlador".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: power/reset: arm-versatile: Se corrige la pérdida de recuento de referencias en versátil_reboot_probe. of_find_matching_node_and_match() devuelve un puntero de nodo con el recuento de referencias incrementado. Deberíamos usar of_node_put() en él cuando ya no lo necesitemos. Se agrega el error of_node_put() faltante para evitar la pérdida de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: VMX: Evitar el desbordamiento de RSB antes de vmenter En VMX, hay algunos retornos equilibrados entre el momento en que se escribe el valor SPEC_CTRL del invitado y el vmenter. Los retornos equilibrados (que coinciden con una llamada anterior) suelen ser correctos, pero al menos es teóricamente posible que un NMI con una pila de llamadas profunda pueda vaciar el RSB antes de uno de los retornos. Para máxima paranoia, no permita *ningún* retorno (equilibrado o de otro tipo) entre la escritura de SPEC_CTRL y el vmenter. [ bp: Arreglar compilación de 32 bits. ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/speculation: Fill RSB on vmexit for IBRS Prevenir ataques de envenenamiento/subdesbordamiento de RSB con RSB. Mientras tanto, agregue una serie de comentarios para intentar documentar el estado actual del conocimiento tribal sobre los ataques RSB y qué se está mitigando exactamente.