Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/hfi1: Corrija el pánico con ipoib send_queue_size más grande Cuando ipoib send_queue_size aumenta respecto del valor predeterminado, ocurre el siguiente pánico: RIP: 0010:hfi1_ipoib_drain_tx_ring+0x45/0xf0 [hfi1] Código: 31 e4 eb 0f 8b 85 c8 02 00 00 41 83 c4 01 44 39 e0 76 60 8b 8d cc 02 00 00 44 89 e3 be 01 00 00 00 d3 e3 48 03 9d c0 02 00 00 83 8 01 00 00 00 00 00 00 48 8b bb 30 01 00 00 e8 25 af a7 e0 RSP: 0018:ffffc9000798f4a0 EFLAGS: 00010286 RAX: 00000000000008000 RBX: ffffc9000aa0f000 RCX: 000000000000000f RDX: 00000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff88810ff08000 R08: ffff88889476d900 R09: 0000000000000101 R10: 0000000000000000 R11: ffffc90006590ff8 R12: 0000000000000200 R13: ffffc9000798fba8 R14: 0000000000000000 R15: 00000000000001 FS: 00007fd0f79cc3c0(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR 2: ffffc9000aa0f118 CR3 : 0000000889c84001 CR4: 00000000001706e0 Seguimiento de llamadas: hfi1_ipoib_napi_tx_disable+0x45/0x60 [hfi1] hfi1_ipoib_dev_stop+0x18/0x80 [hfi1] [ib_ipoib] ipoib_stop+0x48/0xc0 [ib_ipoib] __dev_close_many+0x9e/0x110 __dev_change_flags+ 0xd9/0x210 dev_change_flags+0x21/0x60 do_setlink+0x31c/0x10f0? __nla_validate_parse+0x12d/0x1a0 ? __nla_parse+0x21/0x30? inet6_validate_link_af+0x5e/0xf0? cpumask_next+0x1f/0x20 ? __snmp6_fill_stats64.isra.53+0xbb/0x140 ? __nla_validate_parse+0x47/0x1a0 __rtnl_newlink+0x530/0x910 ? pskb_expand_head+0x73/0x300? __kmalloc_node_track_caller+0x109/0x280 ? __nla_put+0xc/0x20 ? cpumask_next_and+0x20/0x30? update_sd_lb_stats.constprop.144+0xd3/0x820? _raw_spin_unlock_irqrestore+0x25/0x37? __wake_up_common_lock+0x87/0xc0? kmem_cache_alloc_trace+0x3d/0x3d0 rtnl_newlink+0x43/0x60 El problema ocurre cuando el cambio que debería haber sido una función del tamaño del elemento txq usó por error el tamaño del anillo. Arreglar usando el tamaño del elemento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf: heaps: repara un posible gadget de Spectre v1. Parece que nr podría ser un gadget de Spectre v1, ya que lo proporciona un usuario y se utiliza como índice de matriz. Evite que el contenido de la memoria del kernel se filtre al espacio de usuario mediante ejecución especulativa utilizando array_index_nospec. [presenta: correcciones agregadas y cc: etiquetas estables]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/kmemleak: evita escanear posibles agujeros enormes. Al usar devm_request_free_mem_region() y devm_memremap_pages() para agregar memoria ZONE_DEVICE, si se solicitaba, el pfn final de la región de memoria libre era enorme (por ejemplo, 0x400000000), el node_end_pfn() también será enorme (ver move_pfn_range_to_zone()). Por lo tanto, crea un enorme agujero entre node_start_pfn() y node_end_pfn(). Descubrimos que en algunas APU AMD, AMDKFD solicitó una región de memoria libre y creó un agujero enorme. En tal caso, el siguiente fragmento de código simplemente estaba haciendo un bucle test_bit() ocupado en el enorme agujero. for (pfn = start_pfn; pfn < end_pfn; pfn++) { estructura página *página = pfn_to_online_page(pfn); si (!página) continúa; ... } Entonces obtuvimos un bloqueo suave: perro guardián: ERROR: bloqueo suave - ¡CPU#6 bloqueada durante 26 segundos! [bash:1221] CPU: 6 PID: 1221 Comm: bash No contaminado 5.15.0-custom #1 RIP: 0010:pfn_to_online_page+0x5/0xd0 Seguimiento de llamadas:? kmemleak_scan+0x16a/0x440 kmemleak_write+0x306/0x3a0 ? common_file_perm+0x72/0x170 full_proxy_write+0x5c/0x90 vfs_write+0xb9/0x260 ksys_write+0x67/0xe0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x3b/0xc0 Entry_SYSCALL_64_after_hwframe+0x4 4/0xae Hice algunas pruebas con el parche. (1) módulo amdgpu descargado antes del parche: usuario real 0m0.976s 0m0.000s sys 0m0.968s después del parche: usuario real 0m0.981s 0m0.000s sys 0m0.973s (2) módulo amdgpu cargado antes del parche: real 0m35 .365s usuario 0m0.000s sys 0m35.354s después del parche: real 0m1.049s usuario 0m0.000s sys 0m1.042s

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau: solucionado por uno en la comprobación de los límites del BIOS. La comprobación de los límites al analizar los scripts de inicio integrados en el BIOS rechaza el acceso al último byte. Esto hace que la inicialización del controlador falle en Apple eMac con GPU GeForce 2 MX, dejando el sistema sin consola funcional. Probablemente esto solo se vea en máquinas OpenFirmware como PowerPC Mac porque la imagen del BIOS proporcionada por OF es solo las partes utilizadas de la ROM, no una potencia de dos bloques leída directamente desde PCI, por lo que las PC siempre tienen bytes vacíos al final que son nunca accedido.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: soluciona el punto muerto entre la desactivación de cuota y el trabajador de rescaneo de qgroup. La desactivación de cuota ioctl inicia una transacción antes de esperar a que se complete el trabajador de rescaneo de qgroup. Sin embargo, esta espera puede ser infinita y provocar un punto muerto debido a la dependencia circular entre el ioctl de desactivación de cuota, el trabajador de rescaneo de qgroup y la otra tarea con transacciones como la tarea de reubicación del grupo de bloques. El punto muerto ocurre con los siguientes pasos: 1) La tarea A llama a ioctl para deshabilitar la cuota. Inicia una transacción y espera a que se complete el trabajo de rescaneo de qgroup. 2) La tarea B, como la tarea de reubicación del grupo de bloques, inicia una transacción y se une a la transacción que inició la tarea A. Luego la tarea B se compromete con la transacción. En esta confirmación, la tarea B espera una confirmación de la tarea A. 3) La tarea C, como trabajador de rescaneo de qgroup, inicia su trabajo e inicia una transacción. En el inicio de esta transacción, la tarea C espera a que se complete la transacción que inició la tarea A y confirmó la tarea B. Este punto muerto se encontró con el caso de prueba btrfs/115 de fstests y un dispositivo null_blk zonificado. El caso de prueba habilita y deshabilita la cuota, y la recuperación del grupo de bloques se activó durante la deshabilitación de la cuota por casualidad. El punto muerto también se observó al ejecutar la habilitación y deshabilitación de cuotas en paralelo con el comando 'btrfs balance' en dispositivos null_blk normales. Un informe de ejemplo del punto muerto: [372.469894] INFORMACIÓN: tarea kworker/u16:6:103 bloqueada durante más de 122 segundos. [372.479944] No contaminado 5.16.0-rc8 #7 [372.485067] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [372.493898] tarea:kworker/u16:6 estado:D pila: 0 pid: 103 ppid: 2 banderas:0x00004000 [372.503285] Cola de trabajo: btrfs-qgroup-rescan btrfs_work_helper [btrfs] [372.510782] Seguimiento de llamadas: [372.521684] __programación+0xb56/0x4850 [372.530104] ? io_schedule_timeout+0x190/0x190 [372.538842] ? lockdep_hardirqs_on+0x7e/0x100 [372.547092] ? _raw_spin_unlock_irqrestore+0x3e/0x60 [372.555591] horario+0xe0/0x270 [372.561894] btrfs_commit_transaction+0x18bb/0x2610 [btrfs] [372.570506] ? btrfs_apply_pending_changes+0x50/0x50 [btrfs] [372.578875] ? free_unref_page+0x3f2/0x650 [372.585484] ? terminar_esperar+0x270/0x270 [372.591594] ? release_extent_buffer+0x224/0x420 [btrfs] [372.599264] btrfs_qgroup_rescan_worker+0xc13/0x10c0 [btrfs] [372.607157] ? lock_release+0x3a9/0x6d0 [372.613054]? btrfs_qgroup_account_extent+0xda0/0xda0 [btrfs] [372.620960]? do_raw_spin_lock+0x11e/0x250 [372.627137]? rwlock_bug.part.0+0x90/0x90 [372.633215] ? lock_is_held_type+0xe4/0x140 [372.639404] btrfs_work_helper+0x1ae/0xa90 [btrfs] [372.646268] Process_one_work+0x7e9/0x1320 [372.652321] ? lock_release+0x6d0/0x6d0 [372.658081]? pwq_dec_nr_in_flight+0x230/0x230 [372.664513] ? rwlock_bug.part.0+0x90/0x90 [372.670529] trabajador_thread+0x59e/0xf90 [372.676172] ? proceso_one_work+0x1320/0x1320 [372.682440] kthread+0x3b9/0x490 [372.687550] ? _raw_spin_unlock_irq+0x24/0x50 [372.693811] ? set_kthread_struct+0x100/0x100 [372.700052] ret_from_fork+0x22/0x30 [372.705517] [372.709747] INFORMACIÓN: tarea btrfs-transacti:2347 bloqueada durante más de 123 segundos. [372.729827] No contaminado 5.16.0-rc8 #7 [372.745907] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [372.767106] tarea: btrfs-transacti estado: D pila: 0 pid: 2347 ppid: 2 banderas: 0x00004000 [372.787776] Seguimiento de llamadas: [372.801652] [372.812961] __schedule+0xb56/0x4850 [372.83 0011] ? io_schedule_timeout+0x190/0x190 [372.852547] ? lockdep_hardirqs_on+0x7e/0x100 [372.871761]? _raw_spin_unlock_irqrestore+0x3e/0x60 [372.886792] horario+0xe0/0x270 [372.901685] ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ALSA: hda: corrige UAF de los desarrolladores de clase LED al desvincularse. Los dispositivos de clase LED creados por controladores de códec de audio HD se registran a través de devm_led_classdev_register() y se asocian con el audio HD. dispositivo códec. Desafortunadamente, resultó que la versión devres no funciona para este caso; es decir, dado que la liberación del recurso del códec ocurre antes de la cadena de llamadas del desarrollador, desencadena una desreferencia NULL o un UAF para una devolución de llamada obsoleta set_brightness_delay. Para corregir el error, este parche cambia el registro y cancelación del registro del dispositivo de clase LED de forma manual sin devres, manteniendo las instancias en hda_gen_spec.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: ops: Rechazar valores fuera de los límites en snd_soc_put_xr_sx() Actualmente no validamos que los valores que se establecen estén dentro del rango que anunciamos en el espacio de usuario como válidos, hágalo y rechazar cualquier valor que esté fuera de rango.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: corrige el use-after-free después de una falla al crear una instantánea En ioctl.c:create_snapshot(), asignamos una estructura de instantánea pendiente y luego la adjuntamos a la lista de transacciones de instantáneas pendientes. Después de eso, llamamos a btrfs_commit_transaction(), y si eso devuelve un error, saltamos a la etiqueta 'falla', donde liberamos() la estructura de instantánea pendiente. Esto puede resultar en un uso posterior después de la liberación de la instantánea pendiente: 1) Asignamos la instantánea pendiente y la agregamos a la lista de instantáneas pendientes de la transacción; 2) Llamamos a btrfs_commit_transaction(), y falla en la primera llamada a btrfs_run_delayed_refs() o btrfs_start_dirty_block_groups(). En ambos casos, no abortamos la transacción y liberamos nuestro identificador de transacción. Saltamos a la etiqueta 'fallo' y liberamos la estructura de instantánea pendiente. Regresamos con la instantánea pendiente todavía en la lista de transacciones; 3) Otra tarea confirma la transacción. Esta vez no hay ningún error y luego, durante la confirmación de la transacción, accede a un puntero a la estructura de instantánea pendiente que la tarea de creación de instantánea ya ha liberado, lo que resulta en una liberación de usuario. En realidad, este problema podría ser detectado por smatch, que produjo la siguiente advertencia: fs/btrfs/ioctl.c:843 create_snapshot() advertencia: '&pending_snapshot->list' no se elimina de la lista. Así que solucione este problema al no tener el ioctl de creación de instantáneas directamente agregue la instantánea pendiente a la lista de transacciones. En su lugar, agregue la instantánea pendiente al identificador de la transacción, y luego en btrfs_commit_transaction() agregamos la instantánea a la lista solo cuando podamos garantizar que cualquier error devuelto después de ese punto resultará en la cancelación de la transacción, en cuyo caso el código ioctl puede Libera la instantánea pendiente y ya nadie podrá acceder a ella.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: isdn: cpai: verifique ctr->cnr para evitar que el índice de matriz esté fuera de límite. cmtp_add_connection() agregaría una sesión cmtp a un controlador y ejecutaría un subproceso del kernel para procesar cmtp. __module_get(ESTE_MÓDULO); sesión->tarea = kthread_run(cmtp_session, sesión, "kcmtpd_ctr_%d", sesión->num); Durante este proceso, el hilo del núcleo llamaría a detach_capi_ctr() para desconectar un controlador de registro. Si el controlador aún no estaba conectado, detach_capi_ctr() desencadenaría un error de los límites de índice de matriz. [ 46.866069][ T6479] UBSAN: índice de matriz fuera de los límites en drivers/isdn/capi/kcapi.c:483:21 [ 46.867196][ T6479] el índice -1 está fuera de rango para el tipo 'capi_ctr *[ 32]' [ 46.867982][ T6479] CPU: 1 PID: 6479 Comm: kcmtpd_ctr_0 No contaminado 5.15.0-rc2+ #8 [ 46.869002][ T6479] Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.14. 0-2 01/04/2014 [ 46.870107][ T6479] Seguimiento de llamadas: [ 46.870473][ T6479] dump_stack_lvl+0x57/0x7d [ 46.870974][ T6479] ubsan_epilogue+0x5/0x40 [ 46.871458][ T6479 ] __ubsan_handle_out_of_bounds.cold+0x43 /0x48 [ 46.872135][ T6479] detach_capi_ctr+0x64/0xc0 [ 46.872639][ T6479] cmtp_session+0x5c8/0x5d0 [ 46.873131][ T6479] ? __init_waitqueue_head+0x60/0x60 [ 46.873712][ T6479] ? cmtp_add_msgpart+0x120/0x120 [ 46.874256][ T6479] kthread+0x147/0x170 [ 46.874709][ T6479] ? set_kthread_struct+0x40/0x40 [ 46.875248][ T6479] ret_from_fork+0x1f/0x30 [ 46.875773][ T6479]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: soluciona una posible pérdida de memoria en intel_setup_irq_remapping() después del commit e3beca48a45b ("irqdomain/treewide: mantiene el nodo de firmware asignado incondicionalmente"). Para el escenario de desmontaje, fn solo se libera después de que no se puede asignar ir_domain, aunque también debe liberarse en caso de que dmar_enable_qi devuelva un error. Además de free fn, irq_domain e ir_msi_domain también deben eliminarse si intel_setup_irq_remapping no logra habilitar la invalidación en cola. Mejore la ruta de rebobinado agregando las etiquetas out_free_ir_domain y out_free_fwnode según la sugerencia de Baolu.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/siw: corrige la fuga de recuento en siw_create_qp() Atomic_inc() debe emparejarse con atomic_dec() en la ruta de error.

Se encontró una vulnerabilidad en LabVantage LIMS 2017. Se calificó como problemática. Este problema afecta un procesamiento desconocido del archivo /labvantage/rc?command=page&page=LV_ViewSampleSpec&oosonly=Y&_sdialog=Y. La manipulación del argumento sdcid/keyid1 conduce a cross site scripting. El ataque puede iniciarse de forma remota. El exploit ha sido divulgado al público y puede utilizarse. A esta vulnerabilidad se le asignó el identificador VDB-269153. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.