Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: marvell: a3700-comphy: corrección de lectura fuera de los límites. Hay un acceso de lectura fuera de los límites de 'gbe_phy_init_fix[fix_idx].addr' en cada iteración después de que 'fix_idx' alcance ' ARRAY_SIZE(gbe_phy_init_fix)'. Asegúrese de que se utilice 'gbe_phy_init[addr]' cuando se manejen todos los elementos de la matriz 'gbe_phy_init_fix'. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: convierte folio_test_hugetlb en un PageType. El folio_test_hugetlb() actual puede ser engañado por una división de folio concurrente y devuelve verdadero para un folio que nunca ha pertenecido a hugetlbfs. Esto no puede suceder si la persona que llama tiene un recuento sobre él, pero tenemos algunos lugares (fallo de memoria, compactación, procfs) que no toman ni deben tomar una referencia especulativa. Dado que las páginas de Hugetlb no usan recuentos de mapas de páginas individuales (siempre están completamente asignadas y usan el campo Whole_mapcount para registrar el número de asignaciones), el campo PageType está disponible ahora que page_mapcount() ignora el valor en este campo. En compactación y con CONFIG_DEBUG_VM habilitado, la implementación actual puede resultar en un error, según lo informado por Luis. Esto sucede desde que 9c5ccf2db04b ("mm: eliminar HUGETLB_PAGE_DTOR") agregó efectivamente algunas comprobaciones de VM_BUG_ON() en la ruta de prueba de PageHuge(). [willy@infradead.org: actualizar vmcoreinfo] Enlace: https://lkml.kernel.org/r/ZgGZUvsdhaT1Va-T@casper.infradead.org

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: qcom: uefisecapp: corrige errores y bloqueos de E/S relacionados con la memoria. Resulta que, si bien el comando QSEECOM APP_SEND tiene campos específicos para los buffers de solicitud y respuesta, uefisecapp espera que ambos estén en una única región de memoria. El incumplimiento de esto ha dado como resultado (hasta ahora) que no se escriba ninguna respuesta en el búfer de respuesta (lo que provoca que se emita un EIO en el futuro), que la llamada SCM falle con EINVAL (es decir, directamente desde TZ/firmware), o el dispositivo para ser reiniciado. Si bien este problema puede desencadenarse de manera determinista, en la forma actual parece ocurrir de manera bastante esporádica (razón por la cual pasó desapercibido durante las pruebas anteriores). Es probable que esto se deba a que las dos llamadas a kzalloc() (para solicitud y respuesta) están directamente una detrás de la otra. Lo que significa que es probable que regresen a regiones consecutivas la mayor parte del tiempo, especialmente cuando no sucede mucho más en el sistema. Solucione este problema asignando una única región de memoria para los búferes de solicitud y respuesta, alineando adecuadamente ambas estructuras dentro de ella. Lamentablemente, esto también significa que la interfaz qcom_scm_qseecom_app_send() debe reestructurarse, ya que ya no debería asignar las regiones DMA por separado. Por lo tanto, traslade la responsabilidad de la asignación (o mapeo) de DMA a la persona que llama.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: CPPC: use access_width sobre bit_width para accesos a la memoria del sistema. Para alinearse con ACPI 6.3+, dado que bit_width puede ser cualquier valor de 8 bits, no se puede depender de que esté siempre encendido. un límite limpio de 8b. Esto fue descubierto en la plataforma Cobalt 100. Interrupción de error en CPU26, código 0xbe000011 - CPU de SError: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Nombre de hardware: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO + TCO -DIT -SSBS BTYPE=--) pc: cppc_get_perf_caps+0xec/0x410 lr: cppc_get_perf_caps+0xe8/0x410 sp: ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: 0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: d04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9: ffffdc7 e111badec x8: ffff00802b251980 x7: 0000000000000000 x6: ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Pánico del kernel - no se sincroniza: SError asíncrono Interrupción CPU: 26 PID: 1510 Comunicación: systemd-udevd No contaminado 5.15.2.1-13 #1 Nombre de hardware: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Rastreo de llamadas: dump_backtrace+0x0/0x1e0 show_stack+0x24/0x30 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x16c/0x384 add_taint+0x0/0xc0 arm64_serror_panic+0x7c/0x9 0 arm64_is_fatal_ras_serror+0x34/0xa4 do_serror+ 0x50/0x6c el1h_64_error_handler+0x40/0x74 el1h_64_error+0x7c/0x80 cppc_get_perf_caps+0xec/0x410 cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq] cpufreq_add_dev+0xc0/0xd4 subsys_interface_register+0x134/0x14c cpufreq_register_driver+0x1b0/0x354 cppc_cpufreq_init+0x1a8/ 0x1000 [cppc_cpufreq] do_one_initcall+0x50/0x250 do_init_module+0x60/0x27c load_module+0x2300/0x2570 __do_sys_finit_module+0xa8/0x114 __arm64_sys_finit_module+0x2c/0x3c invoke_ llamada al sistema+0x78/0x100 el0_svc_common.constprop.0+0x180/0x1a0 do_el0_svc+0x84/0xa0 el0_svc+ 0x2c/0xc0 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 En su lugar, use access_width para determinar el tamaño y use el desplazamiento y el ancho para desplazar y enmascarar los bits para leer/escribir. Asegúrese de agregar una verificación de la memoria del sistema, ya que pcc redefine el ancho de acceso al ID del subespacio. Si access_width no está configurado, vuelva a utilizar bit_width. [rjw: ediciones de asunto y registro de cambios, ajustes de comentarios]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: corrige TASK_SIZE en NOMMU de 64 bits En NOMMU, la memoria del espacio de usuario puede provenir de cualquier lugar de la RAM física. La definición actual de TASK_SIZE es incorrecta si existe RAM por encima de 4G, lo que provoca fallos falsos en las rutinas de acceso al espacio de usuario.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dma: xilinx_dpdma: bloqueo de reparación Hay varios lugares donde chan->lock o chan->vchan.lock no se mantuvieron. Agregue el bloqueo apropiado. Esto corrige advertencias de bloqueo como [31.077578] ------------[ cortar aquí ]------------ [ 31.077831] ADVERTENCIA: CPU: 2 PID: 40 en los controladores/ dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.077953] Módulos vinculados en: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 No contaminado 6.6.20+ #98 [ 31.07 8102] Nombre del hardware : xlnx,zynqmp (DT) [31.078169] Cola de trabajo: events_unbound deferred_probe_work_func [31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [31.078377] pc: xilinx_dpdma_chan_queue _transfer+0x274/0x5e0 [ 31.078473 ] lr: xilinx_dpdma_chan_queue_transfer+0x270/0x5e0 [31.078550] sp: ffffffc083bb2e10 [31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: 65a168 [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 0000000000000000 [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000 [ 31.079295] x17: 0000000000000000 x16: 00000000000000000 x15: 0000000000000000 [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001 [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9: 0001ffc082aa3def [31.079824 ] x8: 0001ffc082aa3dec x7: 0000000000000000 x6: 0000000000000516 [31.079982] x5: ffffffc7f8d43000 x4: ffffff88003c9c40 x3: ffffffffffffffff [ 31.0 80147] x2: ffffffc7f8d43000 x1: 00000000000000c0 x0: 0000000000000000 [31.080307] Rastreo de llamadas: [31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [31. 080518 ] xilinx_dpdma_issue_pending+0x11c/0x120 [ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac [ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c [ 31.080825] helper_commit_planes+0x20c/0x684 [ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0 [ 31.081139] commit_tail+0x234/0x294 [ 31.081246] drm_atomic_helper_commit +0x1f8/0x210 [ 31.081363] drm_atomic_commit+0x100/0x140 [ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384 [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c [ 31.081725] drm_client_modeset_commit+0x34/0x5c [ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168 [ 31.081899] drm_fb_helper_set_par+0x50 /0x70 [ 31.081971] fbcon_init+0x538/0xc48 [ 31.082047] visual_init+0x16c/0x23c [ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634 [ 31.082320] x24c/0x33c [ 31.082429] do_fbcon_takeover+0xbc/0x1b0 [ 31.082503] fbcon_fb_registered +0x2d0/0x34c [ 31.082663] Register_framebuffer+0x27c/0x38c [ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c [ 31.082939] drm_fb_helper_initial_config+0x50/0x74 [ 3 1.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108 [ 31.083115] drm_client_register+0xa0/0xf4 [ 31.083195] drm_fbdev_dma_setup+0xb0 /0x1cc [ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0 [ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0 [ 31.083616] platform_probe+0x8c/0x13c [ 31.083713] +0x258/0x59c [ 31.083793] __driver_probe_device+0xc4/0x224 [ 31.083878] driver_probe_device+0x70/0x1c0 [ 31.083961] __device_attach_driver+0x108/0x1e0 [ 31.084052] bus_for_each_drv+0x9c/0x100 [ 31.084125] __device_attach+0x100/0x298 [ 31.084207 device_initial_probe+0x14/0 x20 [ 31.084292] bus_probe_device+0xd8/0xdc [ 31.084368] deferred_probe_work_func+0x11c/0x180 [ 31.084451 ] Process_one_work+0x3ac/0x988 [31.084643] work_thread+0x398/0x694 [31.084752] kthread+0x1bc/0x1c0 [31.084848] ret_from_fork+0x10/0x20 [31.084932] sello de evento irq: 9 [31.084970] hardirqs habilitado por última vez en (64548): [ ] _raw_spin_unlock_irqrestore+0x80/0x90 [31.085157] ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cpu: vuelva a habilitar las mitigaciones de CPU de forma predeterminada para arquitecturas !X86. Cambie el nombre de x86 a CPU_MITIGATION, defínalo en código genérico y fuércelo para todas las arquitecturas con excepción de x86. Una confirmación reciente para desactivar las mitigaciones de forma predeterminada si SPECULATION_MITIGATION=n pasó por alto que "cpu_mitigations" es completamente genérico, mientras que SPECULATION_MITIGATIONS es específico de x86. Cambie el nombre de SPECULATIVE_MITIGATION de x86 en lugar de conservar ambos y haga que seleccione CPU_MITIGATION, ya que tener dos configuraciones para lo mismo es innecesario y confuso. Esto también permitirá que x86 use la perilla para administrar mitigaciones que no están estrictamente relacionadas con la ejecución especulativa. Utilice otro Kconfig para comunicar al código común que CPU_MITIGACIONES ya está definida en lugar de que el menú de x86 dependa de CPU_MITIGACIONES comunes. Esto permite mantener un único punto de contacto para todas las mitigaciones de x86, y no está claro que otras arquitecturas *quieran* permitir deshabilitar las mitigaciones en tiempo de compilación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: i2c-hid: elimine el indicador I2C_HID_READ_PENDING para evitar el bloqueo. El indicador I2C_HID_READ_PENDING se utiliza para serializar operaciones I2C. Sin embargo, esto no es necesario, porque el núcleo I2C ya tiene su propio bloqueo para ello. Más importante aún, este indicador puede causar un bloqueo: si el indicador está configurado en i2c_hid_xfer() y ocurre una interrupción, el controlador de interrupciones (i2c_hid_irq) verificará este indicador y regresará inmediatamente sin hacer nada, entonces se invocará el controlador de interrupciones. nuevamente en un bucle infinito. Dado que el controlador de interrupciones es una tarea RT, se hace cargo de la CPU y la tarea de limpieza de banderas nunca se programa, por lo que tenemos un bloqueo. Elimine esta bandera innecesaria.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bnxt_en: corrige una posible pérdida de memoria en bnxt_rdma_aux_device_init() Si ulp = kzalloc() falla, el edev asignado se perderá porque no está asignado correctamente y la ruta de limpieza no podrá liberarlo. Solucionarlo asignándolo correctamente inmediatamente después de la asignación.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: octeontx2-pf: corrige la fuga de recursos del programador de transmisión. Para admitir la configuración y la programación, al crear la clase, el controlador Netdev asigna programadores de transmisión. El parche anterior que agregó soporte para la programación por turnos tiene un error debido a que el controlador no libera los programadores de transmisión después de la eliminación de la clase. Este parche soluciona lo mismo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: plataforma/chrome: cros_ec_uart: corrige correctamente la condición de ejecución. La función cros_ec_uart_probe() llama a devm_serdev_device_open() antes de llamar a serdev_device_set_client_ops(). Esto puede desencadenar una desreferencia del puntero NULL: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000... Seguimiento de llamadas: ...? ttyport_receive_buf Una versión simplificada del código de bloqueo es la siguiente: static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) { struct serdev_device *serdev = ctrl->serdev; if (!serdev || !serdev->ops->receive_buf) // ¡CRASH! devolver 0; devolver serdev->ops->receive_buf(serdev, datos, recuento); } Se supone que si SERPORT_ACTIVE está configurado y serdev existe, serdev->ops también existirá. Esto entra en conflicto con la lógica cros_ec_uart_probe() existente, ya que primero llama a devm_serdev_device_open() (que configura SERPORT_ACTIVE), y solo luego configura serdev->ops a través de serdev_device_set_client_ops(). La confirmación 01f95d42b8f4 ("plataforma/chrome: cros_ec_uart: arreglar condición de ejecución") intentó arreglar una condición de ejecución similar, pero al hacerlo, hizo que la ventana de error para que esta condición de ejecución ocurriera fuera mucho más amplia. Intente corregir la condición de ejecución nuevamente, asegurándose de realizar la configuración completa antes de llamar a devm_serdev_device_open().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: raid1: corrige el uso después de liberar la biografía original en raid1_write_request() r1_bio->bios[] se usa para registrar nuevas biografías que se emitirán a los discos subyacentes; sin embargo, en raid1_write_request(), r1_bio->bios[] se configurará temporalmente en la biografía original. Mientras tanto, si se establece rdev bloqueado, se llamará a free_r1bio() causando que todos los r1_bio->bios[] sean liberados: raid1_write_request() r1_bio = alloc_r1bio(mddev, bio); -> r1_bio->bios[] es NULL para (i = 0; i < discos; i++) -> para cada rdev en conf // el primer rdev es normal r1_bio->bios[0] = bio; -> establecer en biografía original // el segundo rdev está bloqueado si (test_bit(Blocked, &rdev->flags)) break if (blocked_rdev) free_r1bio() put_all_bios() bio_put(r1_bio->bios[0]) -> biografía original es Scripts de prueba liberados: mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-clean fio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs= 1 \ -io Depth=128 -name=test -direct=1 eco bloqueado > /sys/block/md0/md/rd2/state Resultado de la prueba: ERROR bio-264 (No contaminado): Objeto ya libre ------ -------------------------------------------------- --------------------- Asignado en mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869 kmem_cache_alloc+0x324/0x480 mempool_alloc_slab+0x24/0x50 mempool_alloc+0x6e /0x220 bio_alloc_bioset+0x1af/0x4d0 blkdev_direct_IO+0x164/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0 io_submit_one+0x5ca/0xb70 __do_sys_io_submit+0x86/0x270 __x64_sys_io_submit+0x22/0x30 do_syscall_64+0xb1/0x210 Entry_SYSCALL_64_after_hwframe+0x6c/0x74 Liberado en mempool_free_slab +0x1f/0x30 edad=1 cpu=1 pid=869 kmem_cache_free+0x28c/0x550 mempool_free_slab+0x1f/0x30 mempool_free+0x40/0x100 bio_free+0x59/0x80 bio_put+0xf0/0x220 free_r1bio+0x74/0xb0 raid1_make_ request+0xadf/0x1150 md_handle_request+ 0xc7/0x3b0 md_submit_bio+0x76/0x130 __submit_bio+0xd8/0x1d0 submit_bio_noacct_nocheck+0x1eb/0x5c0 submit_bio_noacct+0x169/0xd40 submit_bio+0xee/0x1d0 blkdev_direct_IO+0x322/0x8a0 _write_iter+0x309/0x440 aio_write+0x139/0x2f0 Dado que las BIOS para los discos subyacentes son aún no asignado, solucione este problema usando mempool_free() directamente para liberar r1_bio.