Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corrige bloqueos de cancelación de sqpoll compartido [736.982891] INFORMACIÓN: tarea iou-sqp-4294:4295 bloqueada durante más de 122 segundos. [ 736.982897] Seguimiento de llamadas: [ 736.982901] agenda+0x68/0xe0 [ 736.982903] io_uring_cancel_sqpoll+0xdb/0x110 [ 736.982908] io_sqpoll_cancel_cb+0x24/0x30 [ 736.982911] io_run_task_work_head+0x28/0x50 [ 736.982913] io_sq_thread+0x4e3/0x720 Llamamos a io_uring_cancel_sqpoll( ) uno por uno para cada ctx, ya sea en sq_thread() o mediante tareas, y está destinado a cancelar todas las solicitudes de un contexto específico. Sin embargo, la función utiliza contadores por tarea para rastrear la cantidad de solicitudes en curso, por lo que cuenta más solicitudes de las disponibles a través de currect io_uring ctx y se pone en suspensión para que aparezcan (por ejemplo, desde IRQ), eso nunca sucederá. Cancele un poco más que antes, es decir, todos los ctx que comparten sqpoll y continúan usando contadores compartidos. No olvide que no debemos eliminar ctx de la lista antes de ejecutar task_work sqpoll-cancel; de lo contrario, la función no podrá encontrar el contexto y se bloqueará.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: staging/intel-ipu3: Corrija el manejo de errores set_fmt Si ocurre un error durante un set_fmt, no sobrescriba los tamaños anteriores con la configuración no válida. Sin este parche, el cumplimiento de v4l2 termina asignando 4 GiB de RAM y provocando los siguientes OOP [38.662975] ipu3-imgu 0000:00:05.0: el búfer swiotlb está lleno (sz: 4096 bytes) [38.662980] DMA: Fuera de SW-IOMMU espacio para 4096 bytes en el dispositivo 0000:00:05.0 [38.663010] falla de protección general: 0000 [#1] PREEMPT SMP

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: staging/intel-ipu3: Reparar pérdida de memoria en imu_fmt Estamos perdiendo la referencia a una memoria asignada si lo intentamos. Cambie el orden del cheque para evitarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: siempre entra en pánico cuando se especifica errores=panic Antes del commit 014c9caa29d3 ("ext4: make ext4_abort() use __ext4_error()"), la siguiente serie de comandos desencadenaría un pánico: 1. mount /dev/sda -o ro,errors=panic test 2. mount /dev/sda -o remount,abort test Después de el commit 014c9caa29d3, volver a montar un sistema de archivos utilizando la opción de montaje de prueba "abort" ya no provocará pánico . Esta confirmación restaurará el comportamiento inmediatamente anterior a el commit 014c9caa29d3. (Sin embargo, tenga en cuenta que el comportamiento del kernel de Linux no ha sido consistente; algunas versiones anteriores del kernel, incluidas 5.4 y 4.19, tampoco entraron en pánico después de usar la opción de montaje "abortar".) Esto también supone un cambio en el comportamiento de larga data; es decir, los siguientes comandos de la serie ahora causarán pánico, cuando antes no lo hacían: 1. mount /dev/sda -o ro,errors=panic test 2. echo test > /sys/fs/ext4/sda/trigger_fs_error Sin embargo, Esto hace que el comportamiento de ext4 sea mucho más consistente, por lo que es algo bueno.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: revisión de corrección para evitar informes falsos positivos de inodos usados incorrectos Commit <50122847007> ("ext4: verificación de corrección para evitar la inicialización de inodos reservados") verifica el grupo de bloques cero y evita la inicialización inodos reservados. Pero en algunos casos especiales, es posible que no todos los inodos reservados pertenezcan al grupo cero, sino que pueden existir en el segundo grupo si formateamos el sistema de archivos a continuación. mkfs.ext4 -b 4096 -g 8192 -N 1024 -I 4096 /dev/sda Por lo tanto, terminará generando un informe falso positivo de un sistema de archivos dañado. Este parche lo soluciona evitando verificar los inodos reservados si no se ponen a cero los bloques de inodos libres.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sfc: ajuste efx->xdp_tx_queue_count con el número real de colas inicializadas. efx->xdp_tx_queue_count se inicializa inicialmente en num_possible_cpus() y luego se usa para asignar y recorrer la búsqueda de efx->xdp_tx_queues formación. Sin embargo, es posible que terminemos sin inicializar todas las ranuras de la matriz con colas reales durante el sondeo. Esto da como resultado, por ejemplo, una desreferencia del puntero NULL, cuando se ejecuta "# ethtool -S ", similar a lo siguiente [2570283.664955][T4126959] ERROR: desreferencia del puntero NULL del kernel, dirección: 000000000000000f8 [2570283.681283][T4126959] # PF: acceso de lectura de supervisor en modo kernel [2570283.695678][T4126959] #PF: error_code(0x0000) - página no presente [2570283.710013][T4126959] PGD 0 P4D 0 [2570283.721649][T4126959] Ups: 0000 [# 1]MPD PTI [2570283.734108][T4126959] CPU: 23 PID: 4126959 Comunicaciones: ethtool Contaminado: GO 5.10.20-cloudflare-2021.3.1 #1 [2570283.752641][T4126959] Nombre de hardware: [2570283.78140 8][T4126959] QEPD: 0010:efx_ethtool_get_stats+0x2ca/0x330 [sfc] [2570283.796073][T4126959] Código: 00 85 c0 74 39 48 8b 95 a8 0f 00 00 48 85 d2 74 2d 31 c0 eb 07 48 8b 95 a8 0f 00 00 48 63 c8 49 83 c4 08 83 c0 01 48 8b 14 ca <48> 8b 92 f8 00 00 00 49 89 54 24 f8 39 85 a0 0f 00 00 77 d7 48 8b [2570283.831259][T4126959] RSP: 0018:ff ffb79a77657ce8 EFLAGS: 00010202 [2570283.845121 ][T4126959] RAX: 0000000000000019 RBX: ffffb799cd0c9280 RCX: 0000000000000018 [2570283.860872][T4126959] RDX: 0000000000000000 RSI: ffff96dd 970ce000 RDI: 0000000000000005 [2570283.876525][T4126959] RBP: ffff96dd86f0a000 R08: ffff96dd970ce480 R09: 000000000000005f [2570283.892014][T4 126959]R10 : ffffb799cd0c9fff R11: ffffb799cd0c9000 R12: ffffb799cd0c94f8 [2570283.907406][T4126959] R13: ffffffffc11b1090 R14: ffff96dd970ce000 R15: ffffffffc11cd66 c [2570283.922705][T4126959] FS: 00007fa7723f8740(0000) GS:ffff96f51fac0000(0000) knlGS:00000000000000000 [2570283.938848][T4126959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2570283.952524][T4126959] CR2: 000000000000000f8 CR3: 0000001a73e6e006 CR4: 00000000007706 e0 [2570283.967529][T4126959] DR0: 00000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 [2570283.982400][T4126959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [2570283.997308][T4126959] PKRU: 55555554 [2570284.007649][T4126959] Seguimiento de llamadas: [257 0284.017598][T4126959] dev_ethtool+0x1832/0x2830 Solucione este problema ajustando efx->xdp_tx_queue_count después de sondear para reflejar el verdadero valor de las ranuras inicializadas en efx->xdp_tx_queues.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sfc: farch: corrige la búsqueda de cola TX en el manejo de eventos TX Estamos comenzando desde una etiqueta TXQ, no un tipo TXQ, por lo que efx_channel_get_tx_queue() es inapropiado (y podría devolver NULL, provocando pánico).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sfc: farch: corrige la búsqueda de la cola TX en el manejo finalizado del vaciado TX. Estamos comenzando desde un número de instancia TXQ ('qid'), no un tipo TXQ, por lo que efx_get_tx_queue() es inapropiado (y podría devolver NULL, lo que provocaría pánico).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/raid1: indica correctamente el error al finalizar una solicitud de escritura fallida. Este parche soluciona un error de corrupción de datos en matrices raid1 que utilizan mapas de bits. Sin esta solución, los bits del mapa de bits de la E/S fallida terminan borrándose. Dado que estamos en el tramo fallido de raid1_end_write_request, es necesario volver a intentar la solicitud (R1BIO_WriteError) o fallar (R1BIO_Degraded).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tpm: efi: use la variable local para calcular el tamaño del registro final Cuando se llama a tpm_read_log_efi varias veces, lo que sucede cuando uno carga y descarga un controlador TPM2 varias veces, entonces la variable global efi_tpm_final_log_size en algún momento se convierte en un número negativo debido a la resta de final_events_preboot_size que ocurre cada vez. Utilice una variable local para evitar este desbordamiento de enteros. El siguiente problema ahora está resuelto: 8 de marzo 15:35:12 kernel hibinst: Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 0.0.0 06/02/2015 8 de marzo 15:35:12 kernel hibinst: Cola de trabajo: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy] 8 de marzo 15:35:12 kernel de hibinst: RIP: 0010:__memcpy+0x12/0x20 8 de marzo 15:35:12 kernel de hibinst: Código: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 8 de marzo 15:35:12 kernel de hibinst: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206 8 de marzo 15:35:12 kernel de hibinst: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ff ffffffffffe0f 8 de marzo 15:35:12 kernel de hibinst: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d 8 de marzo 15:35:12 kernel de hibinst: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000 000007e9d6073 8 de marzo 15:35:12 kernel hibinst: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5 8 de marzo 15:35:12 kernel de hibinst: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018 8 de marzo 15:35:12 kernel de hibinst: FS: 0000000000000000(0000) GS:ffff8 8f87bd00000(0000) knlGS:0000000000000000 8 de marzo a las 15:35: 12 kernel de hibinst: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 8 de marzo 15:35:12 kernel de hibinst: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0 8 de marzo 15:35:12 kernel de hibinst: Seguimiento de llamadas: 8 de marzo 15:35:12 Hibinst Kernel: tpm_read_log_efi+0x152/0x1a7 mar 8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0 mar 8 15:35:12 hibinst kernel: tpm_chip_register kernel de hibinst: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy] 8 de marzo 15:35:12 kernel de hibinst: Process_one_work+0x1b4/0x370 8 de marzo 15:35:12 kernel de hibinst: work_thread+0x53/0x3e0 8 de marzo 15:35:12 kernel de hibinst : ? proceso_un_trabajo+0x370/0x370

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFS: fs_context: valida las retransmisiones UDP para evitar cambios fuera de los límites. Corrige cambios fuera de los límites en xprt_calc_majortimeo(). Esto se debe a que se pasa una opción de montaje de tiempo de espera de basura (retransmisión) al montaje nfs, en este caso desde syzkaller. Si el protocolo es XPRT_TRANSPORT_UDP, entonces 'retrans' es un valor de desplazamiento para un entero largo de 64 bits, por lo que 'retrans' no puede ser >= 64. Si es >= 64, falla el montaje y devuelve un error.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ACPI: GTDT: no corrompe las asignaciones de interrupciones en caso de falla de la sonda de vigilancia. Cuando falla la sonda del controlador debido a propiedades de firmware no válidas, el controlador GTDT desasigna la interrupción que asignó anteriormente. Sin embargo, nunca comprueba si el mapeo de la interrupción realmente tuvo éxito. Aún más, si el firmware informa un número de interrupción ilegal que se superpone con el rango GIC SGI, esto puede resultar en que un IPI no se asigne y en posteriores fuegos artificiales (según lo informado por Dann Frazier). Vuelva a trabajar el controlador para que tenga un comportamiento un poco más sensato y verifique si la interrupción se ha asignado antes de desasignar las cosas.