Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv4: Se ha corregido una ejecución de datos en torno a sysctl_fib_sync_mem. Al leer sysctl_fib_sync_mem, se puede modificar simultáneamente. Por lo tanto, debemos agregar READ_ONCE() para evitar una ejecución de datos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: rt7*-sdw: endurecer el controlador jack_detect_handler Los controladores de códec de auriculares Realtek normalmente comprueban si la tarjeta está instanciada antes de continuar con la detección del conector. Sin embargo, a los modelos rt700, rt711 y rt711-sdca les falta una comprobación en el puntero de la tarjeta, lo que puede provocar desreferencias NULL en las pruebas de vinculación/desvinculación del controlador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: sof_sdw: gestión de errores en el registro de la tarjeta Si el registro de la tarjeta falla, generalmente debido a sondeos diferidos, las propiedades del dispositivo agregadas para los códecs de auriculares no se eliminan, lo que genera errores del kernel en las pruebas de vinculación/desvinculación del controlador. Ya limpiamos las propiedades del dispositivo cuando se quita la tarjeta, este código se puede mover como ayudante y llamar en caso de errores de registro de la tarjeta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: aspeed: Se corrige la posible desreferenciación de NULL en aspeed_pinmux_set_mux() pdesc podría ser nulo, pero aún así desreferenciar pdesc->name y esto conducirá a un acceso a un puntero nulo. Por lo tanto, movemos una verificación de valores nulos antes de la desreferenciación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: sfp: se corrige la pérdida de memoria en sfp_probe() sfp_probe() asigna un fragmento de memoria de sfp con sfp_alloc(). Cuando devm_add_action() falla, sfp no se libera, lo que provoca una pérdida de memoria. Deberíamos utilizar devm_add_action_or_reset() en lugar de devm_add_action().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tipc: corrige una posible pérdida de recuento de referencias en tipc_sk_create(). Libera sk en caso de que tipc_sk_insert() falle.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: pmac32-cpufreq: Corregir error de pérdida de recuento de referencias En pmac_cpufreq_init_MacRISC3(), necesitamos agregar of_node_put() correspondiente para los tres punteros de nodo cuyo recuento de referencias se ha incrementado mediante of_find_node_by_name().

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