Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: Sincronizar las asignaciones de kernel de la tabla de páginas efi antes de cambiar La tabla de páginas efi se crea inicialmente como una copia de la tabla de páginas del kernel. Con VMAP_STACK habilitado, las pilas del kernel se asignan en el área vmalloc: si la pila se asigna en un nuevo PGD (uno que no estaba presente en el momento de la creación de la tabla de páginas efi o no se sincronizó en un error vmalloc anterior), el kernel tomará una trampa al cambiar a la tabla de páginas efi cuando se accede a la pila del kernel vmalloc, lo que resulta en un pánico del kernel. Solucione eso actualizando las asignaciones de kernel efi antes de cambiar a la tabla de páginas efi.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: sja1105: evitar acceso fuera de los límites en sja1105_init_l2_policing() La familia SJA1105 tiene 45 entradas de tabla de control de L2 (SJA1105_MAX_L2_POLICING_COUNT) y SJA1110 tiene 110 (SJA1110_MAX_L2_POLICING_COUNT). Mantener la estructura de la tabla pero tener en cuenta la diferencia en el recuento de puertos (5 en SJA1105 frente a 10 en SJA1110) no explica completamente la diferencia. En cambio, SJA1110 también tiene controladores de ingreso de L2 para tráfico de multidifusión. Si un paquete se clasifica como de multidifusión, será procesado por el índice de controlador 99 + SRCPORT. La función sja1105_init_l2_policing() inicializa todos los controladores de L2 de modo que no interfieran con la recepción normal de paquetes de forma predeterminada. Para tener un código común entre SJA1105 y SJA1110, se calcula el índice del controlador de multidifusión para el puerto porque es un índice que está fuera de los límites para SJA1105 pero dentro de los límites para SJA1110, y se realiza una comprobación de los límites. El código no hace lo correcto al determinar qué hacer con el controlador de multidifusión del puerto 0 en SJA1105 (ds->num_ports = 5). El índice "mcast" será igual a 45, que también es igual a table->ops->max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). Por lo tanto, pasa por la comprobación. Pero al mismo tiempo, SJA1105 no tiene controladores de multidifusión. Por lo tanto, el código programa el campo SHARINDX de un elemento fuera de los límites en la tabla de control L2 de la configuración estática. La comparación entre las entradas del índice 45 y 45 debería haber determinado que el código no accediera a este índice de control en SJA1105, ya que su memoria ni siquiera estaba asignada. Con suficiente mala suerte, la escritura fuera de los límites podría incluso sobrescribir otros datos válidos del kernel, pero en este caso, el problema se detectó mediante KASAN. Registro del núcleo: sja1105 spi5.0: Chip conmutador sondeado: SJA1105Q ===================================================================== ERROR: KASAN: slab fuera de los límites en sja1105_setup+0x1cbc/0x2340 Escritura de tamaño 8 en la dirección ffffff880bd57708 por la tarea kworker/u8:0/8 ... Cola de trabajo: events_unbound deferred_probe_work_func Rastreo de llamadas: ... sja1105_setup+0x1cbc/0x2340 dsa_register_switch+0x1284/0x18d0 sja1105_probe+0x748/0x840 ... Asignado por la tarea 8: ... sja1105_setup+0x1bcc/0x2340 dsa_register_switch+0x1284/0x18d0 sja1105_probe+0x748/0x840 ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/shmem-helper: eliminar una ubicación errada en la ruta de error drm_gem_shmem_mmap() no posee esta referencia, lo que provoca que el objeto GEM se libere prematuramente y lleve a un use after free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: Se soluciona el fallo al volver a conectar controladores falsos de CSR Parece que los clones falsos de CSR 5.0 pueden provocar que el notificador de suspensión se registre dos veces, lo que provoca el siguiente pánico del kernel: [ 71.986122] Seguimiento de llamadas: [ 71.986124] [ 71.986125] blocking_notifier_chain_register+0x33/0x60 [ 71.986130] hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da] [ 71.986154] btusb_probe+0x979/0xd85 [btusb es: e1e0605a4f4c01984a4b9c8ac58c3666ae287477] [ 71.986159] ? __pm_runtime_set_status+0x1a9/0x300 [ 71.986162] ? ktime_get_mono_fast_ns+0x3e/0x90 [ 71.986167] interfaz_sonda_usb+0xe3/0x2b0 [ 71.986171] realmente_sonda+0xdb/0x380 [ 71.986174] ? pm_runtime_barrier+0x54/0x90 [ 71.986177] __driver_probe_device+0x78/0x170 [ 71.986180] __driver_probe_device+0x1f/0x90 [ 71.986183] __device_attach_driver+0x89/0x110 [ 71.986186] ? driver_allows_async_probing+0x70/0x70 [ 71.986189] bus_para_cada_unidad+0x8c/0xe0 [ 71.986192] __dispositivo_adjunto+0xb2/0x1e0 [ 71.986195] bus_sondeo_dispositivo+0x92/0xb0 [ 71.986198] dispositivo_agregado+0x422/0x9a0 [ 71.986201] ? usb_probe_device+0x3a/0x110 [ 71.986213] realmente_probe+0xdb/0x380 [ 71.986216] ? pm_runtime_barrier+0x54/0x90 [ 71.986219] __driver_probe_device+0x78/0x170 [ 71.986221] driver_probe_device+0x1f/0x90 [ 71.986224] __device_attach_driver+0x89/0x110 [ 71.986227] ? driver_allows_async_probing+0x70/0x70 [ 71.986230] bus_para_cada_unidad+0x8c/0xe0 [ 71.986232] __device_attach+0xb2/0x1e0 [ 71.986235] bus_probe_device+0x92/0xb0 [ 71.986237] device_add+0x422/0x9a0 [ 71.986239] ? _dev_info+0x7d/0x98 [ 71.986242] ? subproceso de rescate+0x3b0/0x3b0 [ 71.986264] kthread+0xdb/0x110 [ 71.986266] ? kthread_complete_and_exit+0x20/0x20 [ 71.986268] ret_from_fork+0x1f/0x30 [ 71.986273] [ 71.986274] ---[ fin de seguimiento 000000000000000 ]--- [ 71.986284] btusb: la sonda de 2-1.6:1.0 falló con el error -17

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: Se corrige un null-ptr-deref en io_tctx_exit_cb() Syzkaller informa un error de desreferencia NULL de la siguiente manera: ERROR: KASAN: null-ptr-deref en io_tctx_exit_cb+0x53/0xd3 Lectura de tamaño 4 en la dirección 0000000000000138 por la tarea file1/1955 CPU: 1 PID: 1955 Comm: file1 No contaminado 6.1.0-rc7-00103-gef4d3ea40565 #75 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Seguimiento de llamadas: nivel_pila_volcado+0xcd/0x134 ? io_tctx_salir_cb+0x53/0xd3 informe_kasan+0xbb/0x1f0 ? io_tctx_salir_cb+0x53/0xd3 rango_comprobación_kasan+0x140/0x190 io_tctx_salir_cb+0x53/0xd3 ejecución_trabajo_tarea+0x164/0x250 ? cancelación_trabajo_tarea+0x30/0x30 obtener_señal+0x1c3/0x2440 ? degradación_bloqueo+0x6e0/0x6e0 ? degradación_bloqueo+0x6e0/0x6e0 ? señales_salida+0x8b0/0x8b0 ? desbloqueo_lectura_sin_datos+0x3b/0x70 ? obtener_sigframe_size+0x10/0x10 ? bloquear_hardirqs_on+0x79/0x100 ? poner_nombre+0xfe/0x140 ? do_execveat_common.isra.0+0x238/0x710 exit_to_user_mode_prepare+0x15f/0x250 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x42/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0023:0x0 Código: No se puede acceder a los bytes del código de operación en 0xffffffffffffffd6. RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000000 RDI: 000000000000000 RBP: 000000000000000 R08: 0000000000000000 R09: 00000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Pánico del kernel: no se sincroniza: panic_on_warn establecido ... Esto sucede porque la adición de task_work desde io_ring_exit_work() no está sincronizada con la cancelación de todos los elementos de trabajo, por ejemplo, de exec. La ejecución de los dos está ordenada de manera que ambos son ejecutados por la propia tarea, pero si io_tctx_exit_cb() está en cola mientras cancelamos todos los elementos de trabajo de exec Y se ejecuta cuando la tarea sale al espacio de usuario en lugar de en el bucle principal en io_uring_cancel_generic(), entonces podemos encontrar current->io_uring == NULL y alcanzar el bloqueo anterior. Es seguro agregar esta verificación NULL aquí, porque la ejecución de las dos rutas las realiza la propia tarea. [axboe: agregue un comentario de código y también coloque una explicación en el mensaje de confirmación]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: slcan: fix freed work crash La prueba LTP pty03 está provocando un fallo en slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 01/04/2014 Cola de trabajo: 0x0 (eventos) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) Código: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Seguimiento de llamadas: worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312) Aparentemente, el tx_work de slcan se libera mientras se programa. Mientras que slcan_netdev_close() (lado netdev) llama a flush_work(&sl->tx_work), slcan_close() (lado tty) no lo hace. Entonces, cuando el netdev nunca se configura, pero el tty está lleno de bytes y se lo obliga a activar la escritura, el trabajo se programa, pero nunca se vacía. Por lo tanto, agregue un flush_work() adicional a slcan_close() para asegurarse de que el trabajo se vacía en todas las circunstancias. el commit de correcciones a continuación movió flush_work() de slcan_close() a slcan_netdev_close(). ¿Cuál fue la razón detrás de esto? ¿Quizás podamos eliminar el que está en slcan_netdev_close()? Veo el mismo patrón en can327. Entonces, tal vez necesite la misma corrección.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mana: Corregir ejecución en la variable per-CQ napi work_done Después de llamar a napi_complete_done(), el bit NAPIF_STATE_SCHED puede borrarse, y otra CPU puede iniciar el hilo napi y acceder a la variable per-CQ, cq->work_done. Si el otro hilo (por ejemplo, desde busy_poll) lo establece en un valor >= budget, este hilo seguirá ejecutándose cuando debería detenerse, y provocará corrupción de memoria y pánico. Para solucionar este problema, guarde la variable per-CQ work_done en una variable local antes de napi_complete_done(), para que no se corrompa por un posible hilo concurrente después de napi_complete_done(). Además, agregue un bit de bandera para anunciar al firmware NIC: la ejecución de la variable NAPI work_done está fija, por lo que el controlador puede soportar de forma fiable funciones como busy_poll.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/gup: fix gup_pud_range() for dax Para dax pud, pud_huge() devuelve true en x86. Por lo tanto, la función funciona siempre que hugetlb esté configurado. Sin embargo, dax no depende de hugetlb. el commit 414fd080d125 ("mm/gup: fix gup_pmd_range() for dax") corrigió los PMD enormes respaldados por devmap, pero omitió los PUD enormes respaldados por devmap. Corrija esto también. Esto corrige el siguiente pánico del kernel: error de protección general, probablemente para la dirección no canónica 0x69e7c000cc478: 0000 [#1] SMP < snip > Call Trace: get_user_pages_fast+0x1f/0x40 iov_iter_get_pages+0xc6/0x3b0 ? mempool_alloc+0x5d/0x170 bio_iov_iter_get_pages+0x82/0x4e0 ? bvec_alloc+0x91/0xc0 ? bio_alloc_bioset+0x19a/0x2a0 blkdev_direct_IO+0x282/0x480 ? __io_complete_rw_common+0xc0/0xc0 ? filemap_range_has_page+0x82/0xc0 generic_file_direct_write+0x9d/0x1a0? inode_update_time+0x24/0x30 __generic_file_write_iter+0xbd/0x1e0 blkdev_write_iter+0xb4/0x150 ? io_import_iovec+0x8d/0x340 io_write+0xf9/0x300 io_issue_sqe+0x3c3/0x1d30 ? sysvec_reschedule_ipi+0x6c/0x80 __io_queue_sqe+0x33/0x240 ? fget+0x76/0xa0 io_submit_sqes+0xe6a/0x18d0 ? __fget_light+0xd1/0x100 __x64_sys_io_uring_enter+0x199/0x880 ? __context_tracking_enter+0x1f/0x70 ? irqentry_exit_to_user_mode+0x24/0x30 ? irqentry_exit+0x1d/0x30 ? __context_tracking_exit+0xe/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fc97c11a7be < snip > ---[ fin del seguimiento 48b2e0e67debcaeb ]--- RIP: 0010:internal_get_user_pages_fast+0x340/0x990 < snip > Pánico del núcleo: no se sincroniza: Excepción fatal Desplazamiento del núcleo: deshabilitado

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: v4l2-dv-timings.c: se corrigen comprobaciones de cordura de borrado demasiado estrictas Se añadieron comprobaciones de cordura para verificar los campos de borrado de v4l2_bt_timings para evitar desbordamientos de enteros cuando el espacio de usuario pasa valores extraños. Pero eso suponía que el espacio de usuario rellenaría correctamente los valores de front porch, back porch y sync, pero a veces todo lo que sabes es el borrado total, que luego se asigna a solo uno de estos campos. Y eso puede fallar con estas comprobaciones. Así que, en su lugar, establece un máximo para el borrado horizontal y vertical total y comprueba que cada campo permanezca por debajo de eso. Eso sigue siendo suficiente para evitar desbordamientos de enteros, pero también permite más flexibilidad en cómo el espacio de usuario rellena estos campos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memcg: corregir posible use after free en memcg_write_event_control() memcg_write_event_control() accede a dentry->d_name del fd de control especificado para enrutar la llamada de escritura. Como no se puede cambiar el nombre de un archivo de interfaz de cgroup, es seguro acceder a d_name siempre que el archivo especificado sea un archivo cgroup normal. Además, como estos archivos de interfaz de cgroup no se pueden eliminar antes del directorio, también es seguro acceder al padre. Antes de 347c4a874710 ("memcg: eliminar cgroup_event->cft"), había una llamada a __file_cft() que verificaba que el archivo especificado es un archivo cgroupfs normal antes de futuros accesos. El puntero cftype devuelto desde __file_cft() ya no era necesario y el commit eliminó inadvertidamente la verificación del tipo de archivo, lo que permitió que cualquier archivo se deslizara. Con las invariantes rotas, los accesos a d_name y a los padres ahora pueden competir contra los cambios de nombre y las eliminaciones de archivos arbitrarios y causar use-after-free. Corrija el error resucitando la comprobación del tipo de archivo en __file_cft(). Ahora que cgroupfs está implementado a través de kernfs, la comprobación de las operaciones de archivo debe pasar por una capa de indirección. En su lugar, verifiquemos el tipo de superbloque y dentry.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fscache: Corregir oops debido a ejecución con cookie_lru y use_cookie Si una cookie caduca desde la LRU y el indicador LRU_DISCARD está configurado, pero la máquina de estado aún no se ha ejecutado, es posible que otro hilo pueda llamar a fscache_use_cookie y comenzar a usarlo. Cuando finalmente se ejecuta cookie_worker, verá el indicador LRU_DISCARD configurado, hará la transición de cookie->state a LRU_DISCARDING, que luego retirará la cookie. Una vez que se retira la cookie, se elimina el objeto, se producirán los siguientes oops porque el objeto asociado con la cookie ahora es NULL. Corrija los oops borrando el bit LRU_DISCARD si otro hilo usa la cookie antes de que se ejecute cookie_worker. ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000008 ... CPU: 31 PID: 44773 Comm: kworker/u130:1 Contaminado: GE 6.0.0-5.dneg.x86_64 #1 Nombre del hardware: Google Compute Engine/Google Compute Engine, BIOS Google 26/08/2022 Cola de trabajo: events_unbound netfs_rreq_write_to_cache_work [netfs] RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... Seguimiento de llamadas: netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs] process_one_work+0x217/0x3e0 worker_thread+0x4a/0x3b0 hilo+0xd6/0x100

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corregir el use after free durante la recuperación de la GPU [Por qué] [ 754.862560] refcount_t: desbordamiento; use after free. [ 754.862898] Seguimiento de llamadas: [ 754.862903] [ 754.862913] amdgpu_job_free_cb+0xc2/0xe1 [amdgpu] [ 754.863543] drm_sched_main.cold+0x34/0x39 [amd_sched] [Cómo] Es posible que fw_fence no se inicialice, verifique si dma_fence_init se realiza antes de la liberación del trabajo