Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: tipos de enteros fijos y ubicaciones de verificación nula [por qué]: problemas solucionados: - comparación con un tipo de entero más amplio en condición de bucle que puede causar bucles infinitos - desreferencia del puntero antes cheque nulo

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: nvidia-shield: agregar comprobaciones de puntero nulo faltantes a la inicialización del LED devm_kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de falla. Asegúrese de que la asignación se haya realizado correctamente comprobando la validez del puntero. [jkosina@suse.com: modificar un poco el registro de cambios]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dmaengine: ti: edma: agregue algunas comprobaciones de puntero nulo a edma_probe devm_kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de falla. Asegúrese de que la asignación se haya realizado correctamente comprobando la validez del puntero.

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: 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 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.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: LoongArch: cambie acpi_core_pic[NR_CPUS] a acpi_core_pic[MAX_CORE_PIC] Con la configuración predeterminada, el valor de NR_CPUS es 64. Cuando la plataforma HW tiene más de 64 cpus, el SYSTEM fallará en estas plataformas . MAX_CORE_PIC es el número máximo de CPU en la tabla MADT (número físico máximo) que puede exceder el número máximo de CPU admitido (NR_CPUS, número lógico máximo), pero el kernel no debería fallar. El kernel debe arrancar los procesadores con NR_CPUS y dejar que los procesadores restantes permanezcan en el BIOS. La posible razón del fallo es que la matriz acpi_core_pic[NR_CPUS] puede desbordarse al analizar la tabla MADT, y es obvio que CORE_PIC debe corresponder al núcleo físico en lugar del núcleo lógico, por lo que es mejor definir la matriz como acpi_core_pic[MAX_CORE_PIC] . Con el parche, el SYSTEM puede iniciar 64 vcpus con el parámetro qemu -smp 128; de lo contrario, el SYSTEM fallará con el siguiente mensaje. [ 0.000000] CPU 0 No se puede manejar la solicitud de paginación del kernel en la dirección virtual 0000420000004259, era == 90000000037a5f0c, ra == 90000000037a46ec [ 0.000000] Ups[#1]: [ 0.000000] CPU: 0 PID: 0 Comm: intercambiador No contaminado 6.8. 0-rc2+ #192 [0.000000] Nombre de hardware: QEMU QEMU Máquina virtual, BIOS desconocido 2/2/2022 [0.000000] pc 90000000037a5f0c ra 90000000037a46ec tp 9000000003c90000 sp 9000000003c93 d60 [ 0.000000] a0 0000000000000019 a1 9000000003d93bc0 a2 0000000000000000 a3 9000000003c93bd8 [ 0.000000] a4 9000000003c93a74 a5 9000000083c93a67 a6 9000000003c938f0 a7 0000000000000005 [ 0.000000] t0 0000420000004201 t1 00000000000000000 t2 0000000000000000 1 t3 0000000000000001 [ 0,000000] t4 0000000000000003 t5 0000000000000000 t6 0000000000000030 t7 0000000000000063 [ 0,000000] t8 0000 000000000014 u0 ffffffffffffffff s9 0000000000000000 s0 9000000003caee98 [ 0.000000] s1 90000000041b0480 s2 9000000003c93da0 s3 9000000003 c93d98 s4 9000000003c93d90 [ 0.000000] s5 9000000003caa000 s6 000000000a7fd000 s7 000000000f556b60 s8 000000000e0a4330 [ 0.000000] ra: 90000000037a46ec platform_init+ 0x214/0x250 [ 0.000000] ERA: 90000000037a5f0c efi_runtime_init+0x30/0x94 [ 0.000000] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 0.000000] PRMD: 00000000 (PPLV0 -PIE -PWE) [ 0.000000] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 0.000000] ECFG: 00070800 (LIE=11 VS=7) [ 0.000000] ESTAT: 00010000 [PIL] (IS= ECode=1 EssubCode=0) [ 0.000000] BADV: 0000420000004259 [ 0.000000] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 0.0000 00] Módulos vinculados en: [ 0.000000] Proceso swapper (pid: 0, threadinfo=(____ptrval____), tarea=(____ptrval____)) [0.000000] Pila: 9000000003c93a14 9000000003800898 90000000041844f8 90000000037a46ec [0.000000] 000000000a7fd000 0000000008290000 0000000000000000 0000000000000000 [ 0.000000] 00000000000000000 0000000000000000 00000000019d 8000 000000000f556b60 [ 0,000000] 000000000a7fd000 000000000f556b08 9000000003ca7700 9000000003800000 [ 0,000000 ] 9000000003c93e50 9000000003800898 9000000003800108 90000000037a484c [ 0.000000] 000000000e0a4330 000000000f556b60 00000000 0a7fd000 000000000f556b08 [ 0.000000] 9000000003ca7700 9000000004184000 0000000000200000 000000000e02b018 [ 0.000000] 000000000a 7fd000 90000000037a0790 9000000003800108 0000000000000000 [ 0.000000] 00000000000000000 000000000e0a4330 000000000f556b60 00000 0000a7fd000 [ 0.000000] 000000000f556b08 000000000eaae298 000000000eaa5040 0000000000200000 [ 0.000000] ... [ 0.000000] Llamar Seguimiento: [ 0.000000] [<90000000037a5f0c>] efi_runtime_init+0x30/0x94 [ 0.000000] [<90000000037a46ec>] platform_init+0x214/0x250 [ 0.000000] [<90000000037a48 4c>] setup_arch+0x124/0x45c [ 0.000000] [<90000000037a0790>] start_kernel +0x90/0x670 [ 0.000000] [<900000000378b0d8>] entrada_kernel+0xd8/0xdc

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet-fc: evita el punto muerto al eliminar la ruta de asociación Al eliminar una asociación, la ruta de cierre se bloquea porque intentamos vaciar el nvmet_wq anidado. Evite este punto muerto al diferir el trabajo colocado en su propio elemento de trabajo.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: arp: Evita el desbordamiento en arp_req_get(). syzkaller informó una escritura desbordada en arp_req_get(). [0] Cuando se emite ioctl(SIOCGARP), arp_req_get() busca una entrada vecina y copia neigh->ha para estructurar arpreq.arp_ha.sa_data. El arp_ha aquí es struct sockaddr, no struct sockaddr_storage, por lo que el búfer sa_data tiene solo 14 bytes. En el siguiente símbolo, se desbordan 2 bytes al siguiente campo int, arp_flags. Inicializamos el campo justo después de memcpy(), por lo que no es un problema. Sin embargo, cuando dev->addr_len es mayor que 22 (por ejemplo, MAX_ADDR_LEN), se sobrescribe arp_netmask, que podría configurarse como htonl(0xFFFFFFFFUL) en arp_ioctl() antes de llamar a arp_req_get(). Para evitar el desbordamiento, limitemos la longitud máxima de memcpy(). Tenga en cuenta que el commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible array in struct sockaddr") simplemente silenció a syzkaller. [0]: memcpy: escritura detectada en todos los campos (tamaño 16) de un solo campo "r->arp_ha.sa_data" en net/ipv4/arp.c:1128 (tamaño 14) ADVERTENCIA: CPU: 0 PID: 144638 en net /ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Módulos vinculados en: CPU: 0 PID: 144638 Comm: syz-executor.4 No contaminado 6.1.74 #31 Nombre de hardware: QEMU PC estándar (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 01/04/2014 RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Código: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 00000000000000000 RBX: ffff88803a815000 RCX: 0000000000000 000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 00000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 0000 7f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4 : 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 000000 0000000400 PKRU: 55555554 Seguimiento de llamadas: arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inet_ioctl+0x314/0x3a0 net/ ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204 sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:870 [en línea] __se_sys_ioctl fs/ioctl.c:856 [en línea] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x37/0x90 arch/x86/ entrada/common.c:81 entrada_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Código: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 0000024 6 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX : 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 00000000000000003 RBP: 00007f172b2d3493 R08: 0 000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ipv6:sr: corrige posible use-after-free y null-ptr-deref La estructura de operaciones pernet para el subsystem debe registrarse antes de registrar la familia netlink genérica.