Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: No suspender la matriz por remodelación interrumpida md_start_sync() suspenderá la matriz si hay repuestos que se pueden agregar o eliminar de conf, sin embargo, si la remodelación aún está en marcha progreso, esto no sucederá en absoluto o los datos se dañarán (no se llamará a remove_and_add_spares desde md_choose_sync_action para remodelar), por lo tanto, no hay necesidad de suspender la matriz si la remodelación aún no se ha realizado. Mientras tanto, existe un posible punto muerto para raid456: 1) se interrumpe la remodelación; 2) configure uno de los discos WantReplacement y agregue un nuevo disco a la matriz; sin embargo, la recuperación no comenzará hasta que finalice la remodelación; 3) luego emita una IO a través de la posición de reshpae, esta IO esperará a que la remodelación avance; 4) continúe remodelando, luego md_start_sync() encontró que hay un disco de repuesto que se puede agregar a conf, se llama a mddev_suspend(); Los pasos 4 y 3 se esperan el uno al otro y se activa el punto muerto. Observé que este problema se encuentra mediante la revisión del código y aún no se ha informado. Solucione este problema al no suspender la matriz durante una remodelación interrumpida, esto es seguro porque la configuración no se cambiará hasta que finalice la remodelación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: No registre sync_thread para remodelar directamente Actualmente, si se interrumpe el proceso de remodelación, volver a ensamblar la matriz registrará sync_thread directamente desde pers->run(), en este caso 'MD_RECOVERY_RUNNING ' se configura directamente, sin embargo, no hay garantía de que md_do_sync() se ejecute, por lo tanto, stop_sync_thread() se bloqueará porque 'MD_RECOVERY_RUNNING' no se puede borrar. En el último parche, asegúrese de que md_do_sync() establezca MD_RECOVERY_DONE; sin embargo, dm-raid test shell/lvconvert-raid-reshape.sh ocasionalmente puede activar el siguiente bloqueo: [root@fedora ~]# cat /proc/1982/stack [<0>] stop_sync_thread+0x1ab/0x270 [md_mod] [<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [<0>] raid_presuspend+0x1e/0x70 [dm_raid] [<0>] dm_table_presuspend_targets+0x40/0xb0 [ dm_mod] [<0>] __dm_destroy+0x2a5/0x310 [dm_mod] [<0>] dm_destroy+0x16/0x30 [dm_mod] [<0>] dev_remove+0x165/0x290 [dm_mod] [<0>] ctl_ioctl+0x4bb/ 0x7b0 [dm_mod] [<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod] [<0>] vfs_ioctl+0x21/0x60 [<0>] __x64_sys_ioctl+0xb9/0xe0 [<0>] do_syscall_64+0xc6/0x230 [<0 >] Entry_SYSCALL_64_after_hwframe+0x6c/0x74 Mientras tanto mddev->recovery es: MD_RECOVERY_RUNNING | MD_RECOVERY_INTR | MD_RECOVERY_RESHAPE | MD_RECOVERY_FROZEN Solucione este problema eliminando el código para registrar sync_thread directamente desde raid10 y raid5. Y deje que md_check_recovery() registre sync_thread.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md: No ignorar la matriz de solo lectura en md_check_recovery() Generalmente, si la matriz no es de lectura y escritura, md_check_recovery() no registrará un nuevo sync_thread en primer lugar. Y si la matriz es de lectura y escritura y sync_thread está registrado, md_set_readonly() cancelará el registro de sync_thread antes de configurar la matriz como de solo lectura. md/raid sigue este comportamiento, por lo que no hay problema. Después de commit f52f5c71f3d4 ("md: arreglar la detención del hilo de sincronización"), el siguiente bloqueo puede activarse mediante test shell/integrity-caching.sh: 1) la matriz es de solo lectura. Superbloque de actualización dm-raid: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> establecer matriz de lectura y escritura md_update_sb 2) registrar un nuevo hilo de sincronización simultáneamente. 3) dm-raid vuelve a configurar la matriz en solo lectura: rs_update_sbs mddev->ro = ro 4) detiene la matriz: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 5) hilo de sincronización realizado: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 6) el hilo del demonio no puede cancelar el registro del hilo de sincronización: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING no se puede borrar, por lo tanto el paso 4 se bloquea; La causa principal es que dm-raid manipula 'mddev->ro' por sí solo; sin embargo, dm-raid realmente debería detener el hilo de sincronización antes de configurar la matriz como de solo lectura. Desafortunadamente, necesito leer más código antes de poder refactorizar el controlador de 'mddev->ro' en dm-raid, por lo tanto, solucionemos el problema de la manera más fácil por ahora para evitar la regresión de dm-raid.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: No ignorar la matriz suspendida en md_check_recovery() mddev_suspend() nunca detiene sync_thread, por lo tanto, no tiene sentido ignorar la matriz suspendida en md_check_recovery(), lo que podría causar sync_thread no se puede cancelar el registro. Después de commit f52f5c71f3d4 ("md: arreglar la detención del hilo de sincronización"), el siguiente bloqueo se puede activar mediante test shell/integrity-caching.sh: 1) suspender la matriz: raid_postsuspend mddev_suspend 2) detener la matriz: raid_dtr md_stop __md_stop_writes stop_sync_thread set_bit(MD_RECOVERY_INTR , &mddev->recuperación); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 3) hilo de sincronización realizado: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 4) el hilo del demonio no puede cancelar el registro del hilo de sincronización: md_check_recovery si (mddev->suspended) regresa; -> devolver directamente md_read_sync_thread clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery); -> MD_RECOVERY_RUNNING no se puede borrar, por lo tanto el paso 2 se bloquea; Este problema no solo está relacionado con dm-raid; solucionelo ignorando la matriz suspendida en md_check_recovery(). Y los parches de seguimiento mejorarán mejor dm-raid para congelar el hilo de sincronización durante la suspensión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/swap: corrige la ejecución al omitir swapcache Al omitir swapcache para SWP_SYNCHRONOUS_IO, si dos o más subprocesos intercambian la misma entrada al mismo tiempo, obtienen páginas diferentes (A, B) . Antes de que un subproceso (T0) finalice el intercambio e instale la página (A) en el PTE, otro subproceso (T1) podría finalizar el intercambio de la página (B), liberar la entrada y luego intercambiar la página posiblemente modificada reutilizando la misma entrada. Rompe el control pte_same (T0) porque el valor de PTE no cambia, lo que provoca un problema de ABA. El subproceso (T0) instalará una página bloqueada (A) en el PTE y provocará daños en los datos. Una posible pila de llamadas es así: CPU0 CPU1 ---- ---- do_swap_page() do_swap_page() con la misma entrada swap_read_folio() < - leer en la página A swap_read_folio() <- leer en la página B ... set_pte_at() swap_free() <- la entrada es libre pte_same() <- Verificar pase, PTE parece no haber cambiado, ¡pero la página A está estancada! swap_free() <- ¡Contenido de la página B perdido! set_pte_at() <- ¡página A obsoleta instalada! Y además, para ZRAM, swap_free() permite que el dispositivo de intercambio descarte el contenido de la entrada, por lo que incluso si la página (B) no se modifica, si swap_read_folio() en CPU0 ocurre más tarde que swap_free() en CPU1, también puede causar que los datos pérdida. Para solucionar este problema, reutilice swapcache_prepare, que fijará la entrada de intercambio usando el indicador de caché y permitirá que solo un hilo la intercambie, y también evitará que cualquier código paralelo coloque la entrada en el caché. Suelte el pasador después de desbloquear el PT. Los corredores simplemente dan vueltas y esperan, ya que es un evento raro y muy corto. Se agrega una llamada Schedule_timeout_uninterruptible(1) para evitar errores repetidos de página que desperdician demasiada CPU, provocando bloqueos en vivo o agregando demasiado ruido a las estadísticas de rendimiento. Un problema similar de livelock se describió en el compromiso 029c4628b2eb ("mm: swap: deshacerse de livelock en swapin readahead") Reproductor: este problema de ejecución se puede activar fácilmente utilizando un reproductor bien construido y un brd parcheado (con un retraso en la ruta de lectura) [ 1]: Con la última línea principal 6.8, la pérdida de datos causada por la ejecución se puede observar fácilmente: $ gcc -g -lpthread test-thread-swap-race.c && ./a.out Contaminando 32 MB de región de memoria... Siga intercambiando. .. Comenzando la ronda 0... Generando 65536 trabajadores... Se generaron 32746 trabajadores, espere a que termine... Ronda 0: Error en 0x5aa00, se esperaban 32746, obtuve 32743, ¡3 pérdida de datos! Ronda 0: Error en 0x395200, se esperaba 32746, obtuve 32743, ¡3 pérdida de datos! Ronda 0: Error en 0x3fd000, esperado 32746, obtuve 32737, ¡9 pérdida de datos! Ronda 0 fallida, ¡15 pérdida de datos! Este reproductor genera múltiples subprocesos que comparten la misma región de memoria mediante un pequeño dispositivo de intercambio. Cada dos subprocesos actualiza las páginas asignadas una por una en dirección opuesta tratando de crear una ejecución, con un subproceso dedicado sigue intercambiando los datos usando madvise. El reproductor creó una tasa de reproducción de aproximadamente una vez cada 5 minutos, por lo que la ejecución debería ser totalmente posible en producción. Después de este parche, ejecuté el reproductor durante más de unos cientos de rondas y no se observó pérdida de datos. ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: target: pscsi: corrige bio_put() para el caso de error A partir del commit 066ff571011d ("bloque: convierte bio_kmalloc en un contenedor kmalloc simple"), una biografía asignada por bio_kmalloc() debe ser liberado por bio_uninit() y kfree(). Esto no se hace correctamente en el caso de error, al presionar WARN y desreferenciar el puntero NULL en bio_free().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/pci: corrige la desactivación de la memoria si el rango DVSEC CXL no coincide con una ventana CFMWS. El subSYSTEM Linux CXL se basa en el supuesto de que HPA == SPA. Es decir, la dirección física del host (HPA) con la que están programados los registros del decodificador HDM son direcciones físicas del SYSTEM (SPA). Durante la configuración del decodificador HDM, los registros de rango DVSEC CXL (cxl-3.1, 8.1.3.8) se verifican si la memoria está habilitada y el rango CXL está en una ventana HPA que se describe en una estructura CFMWS del puente de host CXL (cxl- 3.1, 9.18.1.3). Ahora, si el HPA no es un SPA, el rango CXL no coincide con una ventana CFMWS y el rango de memoria CXL se desactivará en ese momento. El descodificador HDM deja de funcionar, lo que provoca que la memoria del SYSTEM se desactive y, además, el SYSTEM se cuelgue durante la inicialización del descodificador HDM, normalmente cuando se inicia un kernel habilitado para CXL. Evite que el SYSTEM se cuelgue y no desactive el decodificador HDM si el rango CXL del decodificador no se encuentra en una ventana CFMWS. Tenga en cuenta que el cambio solo soluciona un problema de hardware, pero no implementa la traducción HPA/SPA. Se puede agregar soporte para esto en una serie de parches de seguimiento.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/pci: omita para manejar errores RAS si el dispositivo CXL.mem está desconectado. El modelo PCI AER no es adecuado para el manejo de errores CXL. Si bien la expectativa es que un dispositivo PCI pueda escalar hasta restablecer el enlace para recuperarse de un evento AER, el mismo restablecimiento en CXL equivale a una conexión en caliente sorpresa de cantidades masivas de memoria. Actualmente, el controlador de errores CXL intenta un manejo optimista de errores para desvincular el dispositivo del controlador cxl_mem después de obtener algunos valores de registro RAS. Esto da como resultado un intento "esperanzador" de desconectar la memoria, pero no hay garantía de que tenga éxito. Una notificación AER posterior después del evento de desvinculación de memdev ya no puede asumir que los registros están asignados. Verifique el enlace de memdev antes de obtener los valores del registro de estado para evitar fallas del tipo: ERROR: no se puede manejar el error de página para la dirección: ffa00000195e9100 #PF: acceso de lectura del supervisor en modo kernel #PF: código_error(0x0000) - página no presente [. ..] RIP: 0010:__cxl_handle_ras+0x30/0x110 [cxl_core] [...] Seguimiento de llamadas: ? __morir+0x24/0x70 ? page_fault_oops+0x82/0x160? kernelmode_fixup_or_oops+0x84/0x110? exc_page_fault+0x113/0x170? asm_exc_page_fault+0x26/0x30? __pfx_dpc_reset_link+0x10/0x10 ? __cxl_handle_ras+0x30/0x110 [cxl_core] ? find_cxl_port+0x59/0x80 [cxl_core] cxl_handle_rp_ras+0xbc/0xd0 [cxl_core] cxl_error_detected+0x6c/0xf0 [cxl_core] report_error_detected+0xc7/0x1c0 pci_walk_bus+0x73/0x90 pcie_do_recovery+0x23f/0x330 A más largo plazo, es posible que sea necesario corregir el comportamiento de desvinculación y PCI_ERS_RESULT_DISCONNECT. ser reemplazado por un nuevo PCI_ERS_RESULT_PANIC.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: dm-crypt: no modifica los datos cuando se utiliza cifrado autenticado Se dijo que el cifrado autenticado podría producir etiquetas no válidas cuando se modifican los datos que se están cifrando [1]. Entonces, solucione este problema copiando primero los datos en la biografía del clon y luego cifrándolos dentro de la biografía del clon. Esto puede reducir el rendimiento, pero es necesario para evitar que el usuario dañe el dispositivo escribiendo datos con O_DIRECT y modificándolos al mismo tiempo. [1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/aio: restringe kiocb_set_cancel_fn() a E/S enviadas a través de libaio. Si se llama a kiocb_set_cancel_fn() para E/S enviadas a través de io_uring, aparece la siguiente advertencia del kernel: ADVERTENCIA: CPU : 3 PID: 368 en fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8 Rastreo de llamadas: kiocb_set_cancel_fn+0x9c/0xa8 ffs_epfile_read_iter+0x144/0x1d0 io_read+0x19c/0x498 io_issue_sqe+0x118/0x27c io_submit_sqes+0x25c/0x5fc __arm64_sys_io_uring_enter+0x104/ 0xab0 invoke_syscall+0x58/0x11c el0_svc_common+0xb4/0xf4 do_el0_svc+0x2c/0xb0 el0_svc+0x2c/0xa4 el0t_64_sync_handler+0x68/0xb4 el0t_64_sync+0x1a4/0x1a8 Solucionar esto configurando el IOC Bandera B_AIO_RW para E/S de lectura y escritura enviada por libaio .

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: deshabilite IRQ antes de init_fn() para CPU que no son de arranque. Deshabilite IRQ antes de init_fn() para CPU que no sean de arranque cuando se conectan en caliente, para silenciar dichas advertencias (y también evitar errores potenciales debido a problemas inesperados). interrupciones): ADVERTENCIA: CPU: 1 PID: 0 en kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280 CPU: 1 PID: 0 Comm: swapper/1 No contaminado 6.6.17+ #1198 pc 90000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0 a0 0000000000000001 a1 0000000000000006 a2 900000000802c040 a3 0000000000000000 a4 00000000000 00001 a5 0000000000000004 a6 00000000000000000 a7 90000000048e3f4c t0 0000000000000001 t1 9000000005c70968 t2 0000000004000000 t3 000 000000005e56e t4 00000000000002e4 t5 0000000000001000 t6 ffffffff80000000 t7 000000000004000040000 t8 9000000007931638 u0 00000000000000006 s 9 0000000000000004 s0 0000000000000001 s1 9000000006356ac0 s2 9000000007244000 s3 0000000000000001 s4 0000000000000001 s5 900000000636f000 s6 7ffffffffffffffff s7 9000000002123940 s8 9000000001ca55f8 ra: 90000000047bd56c tlb_init+0x24c/0x52 8 ERA: 90000000048e3334 rcu_cpu_starting+0x214/0x280 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000000 (PPLV0 -PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071000 (LIE=12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EssubCode=0) PRID: 0014c010 (Loongson -64 bits, Loongson-3A5000) CPU: 1 PID: 0 Comunicaciones: intercambiador/1 No contaminado 6.6.17+ #1198 Pila: 0000000000000000 9000000006375000 9000000005b61878 900000010039c000 9000 00010039fa30 0000000000000000 900000010039fa38 900000000619a140 9000000006456888 9000000006456880 900000010039f950 0000000000000 0001 0000000000000001 cb0cb028ec7e52e1 0000000002b90000 9000000100348700 00000000000000000 000000000000000001 ffffffff916d12f1 00000000 00000003 0000000000040000 9000000007930370 0000000002b90000 0000000000000004 9000000006366000 900000000619a140 0000000000000000 00000000000000004 0000000000000000 0000 000000000009 ffffffffffc681f2 9000000002123940 9000000001ca55f8 9000000006366000 90000000047a4828 00007ffff057ded8 00000000000000b0 000 0000000000000 0000000000000000 0000000000071000 ... Seguimiento de llamadas: [<90000000047a4828>] show_stack+0x48/0x1a0 [<9000000005b61874>] dump_stack_lvl+0x84/0xcc [< 90000000047f60ac>] __advertir +0x8c/0x1e0 [<9000000005b0ab34>] report_bug+0x1b4/0x280 [<9000000005b63110>] do_bp+0x2d0/0x480 [<90000000047a2e20>] handle_bp+0x120/0x1c0 [<90000 000048e3334>] rcu_cpu_starting+0x214/0x280 [<90000000047bd568>] tlb_init +0x248/0x528 [<90000000047a4c44>] per_cpu_trap_init+0x124/0x160 [<90000000047a19f4>] cpu_probe+0x494/0xa00 [<90000000047b551c>] start_secondary+0x3c/0xc0 [ <9000000005b66134>] smpboot_entry+0x50/0x58

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: IB/hfi1: Corrija el error sdma.h tx->num_descs off-by-one Desafortunadamente, el commit `fd8958efe877` introdujo otro error que provocó que la matriz `descs` se desbordara. Esto da como resultado más fallas fácilmente reproducibles mediante la llamada al SYSTEM "sendmsg". [ 1080.836473] falla de protección general, probablemente para dirección no canónica 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI [ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1] -- [1080.974535] Seguimiento de llamadas: [ 1080.976990] [ 1081.021929] hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1] [ 1081.027364] hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1] [ 1081.032633] h fi1_ipoib_send+0x112/0x300 [hfi1] [ 1081.042001] ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib] [ 1081.046978] dev_hard_start_xmit+0xc4/0x210 -- [ 1081.148347] __sys_sendmsg+0x59/0xa0 crash> ipoib_txreq 0xffff9cfeba229f00 struct ipoib_txreq { txreq = { list = { next = 0xffff9cfe ba229f00, anterior = 0xffff9cfeba229f00}, descp = 0xffff9cfeba229f40, coalesce_buf = 0x0, espera = 0xffff9cfea4e69a48, completo = 0xffffffffc0fe0760 , paquete_len = 0x46d, tlen = 0x0, num_desc = 0x0, desc_limit = 0x6, next_descq_idx = 0x45c, coalesce_idx = 0x0, banderas = 0x0 , descs = {{ qw = {0x8024000120dffb00, 0x4} # SDMA_DESC0_FIRST_DESC_FLAG (bit 63) }, { qw = { 0x3800014231b108, 0x4} }, { qw = { 0x310000e4ee0fcf0, 0x8} }, { qw = { 0x3000012e9f8000, 0x8} }, { qw = { 0x59000dfb9d0000, 0x8} }, { qw = { 0x78000e02e40000, 0x8} }} }, sdma_hdr = 0x400300015528b000, <<< puntero no válido en la estructura de solicitud de tx sdma_status = 0x0, SDMA_DESC0_LAST_DESC_FLAG (bit 62) completo = 0x0, priv = 0x0, txq = 0xffff9cfea4e69880, skb = 0xffff9d099809f400 } Si es un SDMA send consta de exactamente 6 descriptores y requiere relleno de dword (en el séptimo descriptor), la matriz de descriptores sdma_txreq no se expande adecuadamente y el paquete se desbordará hacia la estructura del contenedor. Esto produce pánico cuando se ejecuta la finalización del envío. El pánico exacto varía dependiendo de qué elementos de la estructura del contenedor se corrompen. La solución es utilizar la expresión correcta en _pad_sdma_tx_descs() para probar la necesidad de expandir la matriz de descriptores. Con este parche los fallos ya no son reproducibles y la máquina está estable.