Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: ucsi: recupera todos los PDO en lugar de solo los primeros 4 commits 4dbc6a4ef06d ("usb: typec: ucsi: guarda objetos de datos de energía en modo PD") introdujo la recuperación de los PDO cuando se conectan a una fuente compatible con PD. Pero solo se reciben los primeros 4 PDO, ya que ese es el número máximo que se puede recuperar a la vez dada la limitación de longitud de MESSAGE_IN (16 bytes). Sin embargo, según las especificaciones de PD, una fuente conectada puede anunciar hasta un máximo de 7 PDO. Si dicha fuente está conectada, es posible que el PPM haya negociado un contrato de energía con uno de los PDO con un índice mayor que 4, y se reflejaría en el campo de posición del objeto del objeto de datos de solicitud (RDO). Esto daría como resultado un acceso fuera de los límites cuando se usa rdo_index() para indexar en la matriz src_pdos en ucsi_psy_get_voltage_now(). Con la ayuda del verificador UBSAN -fsanitize=array-bounds habilitado, este problema exacto se revela cuando se conecta a un adaptador de fuente PD que anuncia 5 PDO y el PPM firma un contrato después de seleccionar el quinto. [ 151.545106][ T70] Excepción inesperada de BRK del kernel en EL1 [ 151.545112][ T70] Error interno: controlador BRK: f2005512 [#1] SMP PREEMPT ... [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c [ 151.545507 ] [ T70] lr : power_supply_show_property+0xc0/0x328 ... [ 151.545542][ T70] Rastreo de llamadas: [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c [ 151.545546][ T70] power_supply_uevent+0x1a4/0x 2f0 [151.545550][T70] dev_uevent+0x200/0x384 [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8 [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c [ 151.545562][ T70] Process_one_work+0x244/0 x6f0 [ 151.545564][ T70] work_thread+0x3e0/0xa64 Nosotros Puede resolver esto recuperando y almacenando hasta un máximo de 7 PDO en la matriz con->src_pdos. Esto implicaría dos llamadas al comando GET_PDOS.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nbd: corrija el puntero NULL en flush_workqueue Abra /dev/nbdX primero, config_refs será 1 y los punteros en nbd_device seguirán siendo nulos. Desconecte /dev/nbdX, luego haga referencia a un recv_workq nulo. La protección de config_refs en nbd_genl_disconnect es inútil. [656.366194] ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000020 [656.368943] #PF: acceso de escritura del supervisor en modo kernel [656.369844] #PF: código_error(0x0002) - página no presente [656.370717] PGD 10cc87067 P 4D 10cc87067 PUD 1074b4067 PMD 0 [656.371693] Ups: 0002 [#1] SMP [656.372242] CPU: 5 PID: 7977 Comm: nbd-client No contaminado 5.11.0-rc5-00040-g76c057c84d28 #1 [656.373661] Nombre de hardware: PC estándar QEMU (i 440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 01/04/2014 [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60 [ 656.376627] Código: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 48 0f b1 55 d [ 656.378934 ] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: 0000000000000000 RBX: 00000000000000000 RCX: 0000000000000000 [ 656.379915 ] RDX: ffff888104cf2600 RSI: fffffffaae8f452 RDI: 0000000000000020 [ 656.380473] RBP: 00000000000000020 R08: 00000000000000000 R09: ffff88813bd6b31 8 [656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00 [ 656.3821 66] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0 : 0000000080050033 [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 656.384927] Seguimiento de llamadas : [656.385111] flux_workqueue+0x92 /0x6c0 [ 656.385395] nbd_disconnect_and_put+0x81/0xd0 [ 656.385716] nbd_genl_disconnect+0x125/0x2a0 [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [ 656 .386422] genl_rcv_msg+0xfc/0x2b0 [656.386685]? nbd_ioctl+0x490/0x490 [656.386954]? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0 [ 656.387354] netlink_rcv_skb+0x62/0x180 [ 656.387638] genl_rcv+0x34/0x60 [ 656.387874] netlink_unicast+0x26d/0x590 [ 6 56.388162] netlink_sendmsg+0x398/0x6c0 [656.388451]? netlink_rcv_skb+0x180/0x180 [656.388750] ____sys_sendmsg+0x1da/0x320 [656.389038] ? ____sys_recvmsg+0x130/0x220 [ 656.389334] ___sys_sendmsg+0x8e/0xf0 [ 656.389605] ? ___sys_recvmsg+0xa2/0xf0 [656.389889] ? handle_mm_fault+0x1671/0x21d0 [ 656.390201] __sys_sendmsg+0x6d/0xe0 [ 656.390464] __x64_sys_sendmsg+0x23/0x30 [ 656.390751] do_syscall_64+0x45/0x70 [656.391017] Entry_SYSCALL_64_after_hwframe+0x44/0xa9 Para solucionarlo, simplemente agregue if (nbd->recv_workq) a nbd_disconnect_and_put().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: comprimir: corregir la condición de ejecución de sobrescritura frente a truncar pos_fsstress testcase presenta un pánico como se muestra a continuación: ------------[ cortar aquí ]--- --------- ¡ERROR del kernel en fs/f2fs/compress.c:1082! código de operación no válido: 0000 [#1] SMP PTI CPU: 4 PID: 2753477 Comm: kworker/u16:2 Contaminado: G OE 5.12.0-rc1-custom #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-2 01/04/2014 Cola de trabajo: reescritura wb_workfn (flush-252:16) RIP: 0010:prepare_compress_overwrite+0x4c0/0x760 [f2fs] Seguimiento de llamadas: f2fs_prepare_compress_overwrite+0x5f/0x80 [f2fs] f2fs_write_cache_pages+ 0x468/0x8a0 [f2fs] f2fs_write_data_pages+0x2a4/0x2f0 [f2fs] do_writepages+0x38/0xc0 __writeback_single_inode+0x44/0x2a0 writeback_sb_inodes+0x223/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0 x290 wb_workfn+0x309/0x500 proceso_one_work+0x220/0x3c0 trabajador_thread+0x53/ 0x420 kthread+0x12f/0x150 ret_from_fork+0x22/0x30 La causa principal es que truncate() puede correr con sobrescritura como se muestra a continuación, por lo que un recuento de referencias restante en la página no puede garantizar que la página se adjunte en el árbol de mapeo todo el tiempo, después del truncamiento, más adelante find_lock_page() puede devolver un puntero NULL. - prepare_compress_overwrite - f2fs_pagecache_get_page - unlock_page - f2fs_setattr - truncate_setsize - truncate_inode_page - delete_from_page_cache - find_lock_page Solucione este problema evitando hacer referencia a la página actualizada.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nvmet-rdma: corrige la deref NULL cuando se completa SEND con error Al ejecutar algo de tráfico y eliminar el enlace en el par, se recibe un error de contador de reintentos excedido. Esto lleva a nvmet_rdma_error_comp que intentó acceder a cq_context para obtener la cola. El cq_context ya no es válido después de la corrección para usar el mecanismo CQ compartido y debe obtenerse de manera similar a cómo se obtiene en otras funciones de wc->qp. [905.786331] nvmet_rdma: El ENVÍO para CQE 0x00000000e3337f90 falló y se superó el contador de reintentos de transporte de estado (12). [905.832048] ERROR: no se puede manejar la desreferencia del puntero NULL del kernel en 0000000000000048 [905.839919] PGD 0 P4D 0 [905.842464] Vaya: 0000 1 SMP NOPTI [905.846144] CPU: 13 PID: 1557 Co mm: kworker/13:1H Kdump: cargado Contaminado : G OE --------- - - 4.18.0-304.el8.x86_64 #1 [ 905.872135] RIP: 0010:nvmet_rdma_error_comp+0x5/0x1b [nvmet_rdma] [ 905.878259] Código: 19 4f c0 e8 89 B3 A5 F6 E9 5B E0 FF FF 0F B7 75 14 4C 89 EA 48 C7 C7 08 1A 4F C0 E8 71 B3 A5 F6 E9 4B E0 FF FF 0F 1F 44 00 00 00 <48> 8B 47 48 48 85 C0 74 08 48 89 c7 e9 98 bf 49 00 e9 c3 e3 ff ff [ 905.897135] RSP: 0018:ffffab601c45fe28 EFLAGS: 00010246 [ 905.902387] RAX: 00000000000000065 RBX: ffff9e729ea2f800 RCX: 0000000000000000 [ 905.909558] RDX: 0000000000000000 RSI: ffff9e72df9567c8 RDI: 00000000000000000 [ 905.916731] RBP : ffff9e729ea2b400 R08: 000000000000074d R09: 0000000000000074 [ 905.923903] R10: 00000000000000000 R11: ffffab601c45fcc0 R12: 00000000000 00010 [ 905.931074] R13: 0000000000000000 R14: 0000000000000010 R15: ffff9e729ea2f400 [ 905.938247] FS: 0000000000000000(0000) GS:ffff9e72 df940000(0000) knlGS:0000000000000000 [ 905.938249] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 905.950067] nvmet_rdma: ENVÍO para CQE 0x00000000c7356cca falló con el contador de reintentos de transporte de estado excedido (12). [ 905.961855] CR2: 0000000000000048 CR3: 000000678d010004 CR4: 00000000007706e0 [ 905.961855] DR0: 00000000000000000 DR1: 00000000000000 00 DR2: 0000000000000000 [ 905.961856] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000000400 [ 905.961857] PKRU: 55555554 [ 906.0 10315] Seguimiento de llamadas: [906.012778 ] __ib_process_cq+0x89/0x170 [ib_core] [ 906.017509] ib_cq_poll_work+0x26/0x80 [ib_core] [ 906.022152] Process_one_work+0x1a7/0x360 [ 906.026182] ? crear_trabajador+0x1a0/0x1a0 [ 906.030123] hilo_trabajador+0x30/0x390 [ 906.033802] ? create_worker+0x1a0/0x1a0 [ 906.037744] kthread+0x116/0x130 [ 906.040988] ? kthread_flush_work_fn+0x10/0x10 [ 906.045456] ret_from_fork+0x1f/0x40

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: kyber: corrige el acceso fuera de los límites cuando se adelanta __blk_mq_sched_bio_merge() obtiene el ctx y el hctx para la CPU actual y pasa el hctx a ->bio_merge(). kyber_bio_merge() luego obtiene nuevamente el ctx para la CPU actual y lo usa para obtener el contexto Kyber correspondiente en el hctx pasado. Sin embargo, el hilo puede ser reemplazado entre las dos llamadas a blk_mq_get_ctx(), y es posible que el ctx devuelto la segunda vez ya no corresponda al hctx pasado. Esto "funciona" accidentalmente la mayor parte del tiempo, pero puede hacer que leamos basura si el segundo ctx proviene de un hctx con más ctx que el primero (es decir, si ctx->index_hw[hctx->type] > hctx- >nr_ctx). Esto se manifestó como este error de índice de matriz UBSAN fuera de los límites informado por Jakub: UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type ' long unsigned int [128]' Seguimiento de llamadas: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480 do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_ fusionar+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100 submit_bio_noacct +0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0 btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440 __extent_writepage_io+0x2b8/0x5e0 __ extensión_writepage+0x28d/0x6e0 extensión_write_cache_pages+0x4d7/0x7a0 extensión_writepages+0xa2/0x110 do_writepages +0x8f/0x180 __writeback_single_inode+0x99/0x7f0 writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660 wb_workfn+0x64d/0xa10 Process_one_work+0x53a/0xa80 work_thread+0x69/0x5b0 kthread+0x20b/0x240 ret_from_fork+0x1f/0x30 solamente Kyber usa hctx, así que solucionelo pasando request_queue a ->bio_merge() en su lugar. BFQ y mq-deadline simplemente usan eso, y Kyber puede mapear las colas él mismo para evitar discrepancias.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ACPI: scan: Corregir pérdida de memoria en una ruta de manejo de errores Si falla 'acpi_device_set_name()' debemos liberar 'acpi_device_bus_id->bus_id' o hay una (potencial) memoria filtración.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc3: gadget: estructura de gadget libre solo después de liberar los puntos finales. Como parte de el commit e81a7018d93a ("usb: dwc3: asignar estructura de gadget dinámicamente"), se agregó dwc3_gadget_release() que libere la estructura dwc->gadget al retirar el dispositivo cuando se llama a usb_del_gadget_udc() en dwc3_gadget_exit(). Sin embargo, simplemente liberar el gadget da como resultado una situación de puntero colgante: los puntos finales creados en dwc3_gadget_init_endpoints() tienen sus miembros dep->endpoint.ep_list encadenados fuera del list_head anclado en dwc->gadget->ep_list. Por lo tanto, cuando se libera dwc->gadget, el primer dwc3_ep de la lista ahora tiene un puntero anterior colgante y lo mismo ocurre con el siguiente puntero de dwc3_ep al final de la lista. El dwc3_gadget_free_endpoints() que sigue dará como resultado un use-after-free cuando llame a list_del(). Esto se detectó habilitando KASAN y realizando una desvinculación del controlador. La reciente confirmación 568262bf5492 ("usb: dwc3: core: Add Shutdown Callback for dwc3") también expone esto como un pánico durante el apagado. Hay algunas posibilidades para solucionar este problema. Una podría ser realizar un list_del() del propio gadget->ep_list que lo elimine del resto de la cadena dwc3_ep. Otro enfoque es lo que hace este parche, al dividir la llamada usb_del_gadget_udc() en sus componentes separados "del" y "put". Esto permite llamar a dwc3_gadget_free_endpoints() antes de que el gadget se libere finalmente con usb_put_gadget().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: userfaultfd: publicar página en ruta de error para evitar BUG_ON Considere la siguiente secuencia de eventos: 1. Userspace emite un ioctl UFFD, que termina llamando a shmem_mfill_atomic_pte(). Contamos con éxito los bloques, usamos shmem_alloc_page(), pero luego copy_from_user() falla. Volvemos -ENOENT. No publicamos la página que asignamos. 2. Nuestra persona que llama detecta este código de error, intenta copiar_from_user() después de descartar mmap_lock y vuelve a intentarlo, volviendo a llamar a shmem_mfill_atomic_pte(). 3. Mientras tanto, digamos que otro proceso llenó los tmpfs que se estaban utilizando. 4. Entonces shmem_mfill_atomic_pte() no logra bloquear la cuenta esta vez y regresa inmediatamente, sin liberar la página. Esto desencadena un BUG_ON en nuestra persona que llama, que afirma que la página siempre debe consumirse, a menos que se devuelva -ENOENT. Para solucionar este problema, detectar si tenemos esa página "colgante" cuando falla la contabilidad y, en caso afirmativo, liberarla antes de regresar.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hfsplus: evita la corrupción al reducir y truncar Creo que hay algunos problemas introducidos por el commit 31651c607151 ("hfsplus: evita el punto muerto en el truncamiento de archivos") HFS+ tiene registros de extensión que siempre contienen 8 extensiones. En caso de que el primer registro de extensión en el archivo de catálogo se llene, se asignan nuevos registros desde el archivo de desbordamiento de extensiones. En caso de que se produzca un truncamiento reducido en la mitad de un registro de extensión que se ubica en un archivo de desbordamiento de extensiones, la lógica en hfsplus_file_truncate() se cambió para que la llamada a hfs_brec_remove() ya no esté protegida. La acción correcta sería simplemente liberar las extensiones que exceden el nuevo tamaño dentro del registro de extensión llamando a hfsplus_free_extents() y luego verificar si se debe eliminar todo el registro de extensión. Sin embargo, dado que la guardia (blk_cnt > start) está ahora después de la llamada a hfs_brec_remove(), esto tiene el efecto desafortunado de que el último registro de extensión coincidente se elimina incondicionalmente. Para reproducir este problema, cree un archivo que tenga al menos 10 extensiones y luego realice un truncamiento reducido hasta la mitad del último registro de extensión, de modo que el número de extensiones restantes no sea menor o divisible por 8. Esto hace que el último registro de extensión ( 8 extensiones) para eliminarse por completo en lugar de truncarse a la mitad. Por tanto, esto provoca corrupción y pérdida de datos. La solución para esto es simplemente verificar si el nuevo final truncado está debajo del inicio de este registro de extensión, lo que hace que sea seguro eliminar el registro de extensión completo. Sin embargo, la llamada a hfs_brec_remove() no se puede mover a su lugar anterior ya que estamos eliminando ->tree_lock y puede provocar una condición de ejecución y la invalidación de la información almacenada en caché, posiblemente corrompiendo los datos del nodo. Otro tema está relacionado con éste. Al ingresar al bloque (blk_cnt > start) no mantenemos ->tree_lock. Salimos del bucle sin mantener el bloqueo, pero hfs_find_exit() lo desbloquea. No estoy seguro de si es posible que otra persona tome el bloqueo bajo nuestros pies, pero puede causar errores difíciles de depurar y desbloqueo prematuro. Aunque no exista ningún riesgo real, el bloqueo siempre debe mantenerse en equilibrio. Tomando así el candado ahora justo antes del control.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/64s: soluciona fallas al alternar la barrera de descarga de entrada. La mitigación de descarga de entrada se puede habilitar/deshabilitar en tiempo de ejecución a través de un archivo debugfs (entry_flush), lo que hace que el kernel se parchee a sí mismo. habilitar/deshabilitar las mitigaciones relevantes. Sin embargo, dependiendo de la mitigación que estemos usando, puede que no sea seguro aplicar ese parche mientras otras CPU están activas. Por ejemplo, el siguiente bloqueo: durmiente[15639]: segfault (11) en c000000000004c20 nip c000000000004c20 lr c000000000004c20 Muestra que regresamos al espacio de usuario con un LR corrupto que apunta al kernel, debido a la ejecución de la llamada parcialmente parcheada a la entrada de respaldo descarga ( es decir, nos perdimos la restauración de LR). Arréglelo haciendo el parche debajo de detener la máquina. Las CPU que no estén aplicando los parches girarán en el núcleo de la lógica de detención de la máquina. Actualmente, eso es suficiente para nuestros propósitos, porque ninguno de los parches que hacemos se aplica a ese código ni a ningún lugar cercano.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: Se corrige use-after-free en i40e_client_subtask() Actualmente la llamada a i40e_client_del_instance libera el objeto pf->cinst, sin embargo se accede a pf->cinst->lan_info después de gratis. Solucione este problema agregando la declaración que falta. Direcciones-Cobertura: ("Leer desde el puntero después de estar libre")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nftables: evitar desbordamientos en nft_hash_buckets() Número de depósitos almacenados en variables de 32 bits, debemos asegurarnos de que no se produzcan desbordamientos en nft_hash_buckets() syzbot inyectó un tamaño == 0x40000000 e informó: UBSAN: desplazamiento fuera de los límites en ./include/linux/log2.h:57:13 el exponente de desplazamiento 64 es demasiado grande para el tipo de 64 bits 'long unsigned int' CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:79 [en línea] dump_stack +0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 __roundup_pow_of_two include/linux/log2.h:57 [en línea] nft_hash_buckets net/netfilter/nft_set_hash.c:411 [en línea] nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652 nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [en línea] nf_tables_newset+0xe62 /0x3110 net/filtro de red /nf_tables_api.c:4322 nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [en línea] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630 netlink_unicast_kernel net/ netlink/af_netlink.c:1312 [en línea] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [en línea] sock_sendmsg +0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_sys llamada_64+0x2d /0x70 arco/x86/entry/common.c:46