Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: afs: Reparar pérdida de página. Hay un bucle en afs_extend_writeback() que agrega páginas adicionales a una escritura que queremos realizar para mejorar la eficiencia de la escritura diferida haciéndola más grande. Sin embargo, este bucle se detiene si llegamos a una página desde la que no podemos escribir de inmediato, pero no elimina la referencia de página que adquirimos especulativamente. Esto se debió a la eliminación del bucle de limpieza cuando el código pasó de usar find_get_pages_contig() a escanear xarray, ya que este último solo obtiene una página a la vez, no un lote. Solucione este problema poniendo la página en un árbitro en un descanso temprano del bucle. Desafortunadamente, no podemos simplemente agregar esa página al pagevec que estamos empleando, ya que revisaremos eso y agregaremos esas páginas a la llamada RPC. Esto se encontró mediante la prueba genérica/074. Pierde ~4GiB de RAM cada vez que se ejecuta, lo que se puede observar con "TOP".

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: afs: corrige la corrupción en las lecturas en fpos 2G-4G desde un servidor OpenAFS. AFS-3 tiene dos variantes RPC de recuperación de datos, FS.FetchData y FS.FetchData64, y conmutadores de cliente afs de Linux. entre ellos cuando se habla con un servidor que no es YFS si el tamaño de lectura, la posición del archivo o la suma de los dos tienen los 32 bits superiores establecidos del valor de 64 bits. Sin embargo, esto es un problema, ya que los campos de posición y longitud del archivo de FS.FetchData son valores *firmados* de 32 bits. Solucione este problema capturando los bits de capacidad obtenidos del servidor de archivos cuando se envía un RPC FS.GetCapabilities, en lugar de simplemente descartarlos, y luego seleccionando el indicador VICED_CAPABILITY_64BITFILES. Esto luego se puede usar para decidir si usar FS.FetchData o FS.FetchData64, y también FS.StoreData o FS.StoreData64, en lugar de usar Upper_32_bits() para activar los valores de los parámetros. Este indicador de capacidades también podría usarse para limitar el tamaño máximo del archivo, pero se deben verificar todos los servidores para eso. Tenga en cuenta que el problema no existe con FS.StoreData, que utiliza valores de 32 bits *sin firmar*. Tampoco es un problema con los servidores Auristor ya que su operación YFS.FetchData64 utiliza valores de 64 bits sin firmar. Esto se puede probar clonando un repositorio de git a través de un cliente OpenAFS en un servidor OpenAFS y luego ejecutando el "estado de git" desde un cliente afs de Linux[1]. Siempre que el clon tenga un archivo de paquete que esté en el rango 2G-4G, el estado de git mostrará errores como: error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack no coincide con el índice error: packfile .git/objects/ pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack no coincide con el índice. Esto se puede observar en el FileLog del servidor y aparece algo como lo siguiente: Dom 29 de agosto 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114 , Anfitrión 192.168.11.201:7001, Id 1001 dom 29 de agosto 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001 dom 29 de agosto 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154 dom 29 de agosto 19:3 1:39 2021 FetchData_RXStyle: tamaño de archivo 2400758866 ... domingo 29 de agosto 19:31:40 2021 SRXAFS_FetchData devuelve 5 Tenga en cuenta la posición del archivo de 18446744071815340032. Esta es la posición del archivo solicitada con signo extendido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio-net: corrige páginas con fugas al compilar skb en modo grande. Intentamos usar build_skb() si tuviéramos suficiente espacio de adaptación. Pero nos olvidamos de liberar las páginas no utilizadas encadenadas vía privada en modo grande, lo que filtrará páginas. Para solucionar este problema, libere las páginas después de compilar el skb en modo grande.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: enetc: corrige el acceso ilegal al leer affinity_hint irq_set_affinity_hit() almacena una referencia al parámetro cpumask_t en el descriptor irq, y se puede acceder a esa referencia más tarde desde irq_affinity_hint_proc_show(). Dado que el parámetro cpu_mask pasado a irq_set_affinity_hit() solo tiene almacenamiento temporal (está en la memoria de la pila), los accesos posteriores a él son ilegales. Por lo tanto, las lecturas del archivo procfs affinity_hint correspondiente pueden dar como resultado una solicitud de paginación. El problema lo soluciona el asistente get_cpu_mask(), que proporciona un almacenamiento permanente para el parámetro cpumask_t.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/qeth: corrige NULL deref en qeth_clear_working_pool_list(). Cuando qeth_set_online() llama a qeth_clear_working_pool_list() para retroceder después de una salida de error de qeth_hardsetup_card(), corremos el riesgo de acceder a la tarjeta ->qdio.in_q antes de que qeth_alloc_qdio_queues() lo asignara mediante qeth_mpc_initialize(). qeth_clear_working_pool_list() luego elimina la referencia a NULL y, al escribir en queue->bufs[i].pool_entry garabatea por todo el núcleo bajo de la CPU. Lo que resulta en un bloqueo cuando esas áreas de núcleo bajo se usan a continuación (por ejemplo, en la siguiente interrupción de verificación de la máquina). Este escenario suele ocurrir cuando el dispositivo se configura en línea por primera vez y sus colas aún no están asignadas. Un error de IO temprano o ciertas configuraciones erróneas (por ejemplo, modo de transporte no coincidente, número de puerto incorrecto) hacen que salgamos del error qeth_hardsetup_card() con card->qdio.in_q todavía siendo NULL. Solucionarlo comprobando que el puntero sea NULL antes de acceder a él. Tenga en cuenta que también tenemos rutas (raras) dentro de qeth_mpc_initialize() donde un cambio de configuración puede hacer que liberemos las colas existentes, esperando que el código posterior las asigne nuevamente. Si luego cometemos un error antes de que ocurra la reasignación, ocurre el mismo error. Analizado por: Heiko Carstens

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: asegúrese de que los skbs tx siempre tengan la extensión MPTCP. Debido a la comparación firmado/sin firmar, la expresión: info->size_goal - skb->len > 0 se evalúa como verdadera cuando el tamaño objetivo Es más pequeño que el tamaño skb. Esto da como resultado una falta de recarga de caché de transmisión, de modo que el skb asignado por el código TCP central carece de las extensiones de skb MPTCP requeridas. Debido a lo anterior, syzbot puede activar el siguiente WARN_ON(): ADVERTENCIA: CPU: 1 PID: 810 en net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366 Módulos vinculados en: CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:mptcp_sendmsg_frag+0x1362 /0x1bc0 net/mptcp/protocol.c:1366 Código: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 <0f> 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9 RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216 RAX: 000000000000697f : 0000000000000000 RCX: ffffc90012107000 RDX: 0000000000040000 RSI : ffffffff88eac9e2 RDI: 0000000000000003 RBP: ffff888078b15780 R08: 0000000000000000 R09: 00000000000000000 R10: ffffffff88eac017 R11: 0000000 R12: ffff88801de0a280 R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0 FS: 00007fd9f866e700(0000) GS:ffff8880b9d0000 0(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol. c:1547 mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003 release_sock+0xb4/0x1b0 net/core/sock.c:3206 sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145 mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749 inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643 sock_sendmsg_nosec net/socket.c:704 [en línea] sock_sendmsg+0xcf/0x120 net/socket.c:724 sock_write_iter+0x2a0/ 0x3e0 net/socket.c:1057 call_write_iter include/linux/fs.h:2163 [en línea] new_sync_write+0x40b/0x640 fs/read_write.c:507 vfs_write+0x7cf/0xae0 fs/read_write.c:594 ksys_write+0x1ee/0x250 fs/read_write.c:647 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9 Código: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 3d 01 f0ffff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000056c038 RCX: 00000000004665f9 RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 00000000000000003 RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038 R13: 0000000000a9fb1f R 14: 00007fd9f866e300 R15: 0000000000022000 Solucione el problema al reescribir la expresión relevante para evitar problemas relacionados con los signos. Nota: size_goal siempre es >= 0. Además, asegúrese de que el skb en el caché tx siempre lleva la extensión relevante.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mwifiex: desactivar el enlace antes de eliminar la interfaz. Podemos bloquearnos al modificar el controlador o restablecer el firmware, porque cfg80211_unregister_wdev() tiene que desactivar el enlace por nosotros. .. que luego agarra el mismo candado wiphy. nl80211_del_interface() ya maneja un caso muy similar, con una buena descripción: /* * Mantenemos RTNL, por lo que esto es seguro, sin RTNL opencount no puede * llegar a 0 y, por lo tanto, rdev no se puede eliminar. * * Necesitamos hacerlo para dev_close(), ya que eso llamará * a los notificadores de netdev, y necesitamos adquirir el mutex allí * pero no sabemos si llegamos allí desde aquí o desde algún otro * lugar (por ejemplo "enlace IP configurado... inactivo"). */ mutex_unlock(&rdev->wiphy.mtx); ... Haga lo mismo con el desmontaje de mwifiex, asegurándose de que primero desconectamos el enlace. Ejemplo de seguimiento de interbloqueo: [247.103516] INFORMACIÓN: tarea rmmod:2119 bloqueada durante más de 123 segundos. [247.110630] No contaminado 5.12.4 #5 [247.115796] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [247.124557] tarea:rmmod estado:D pila: 0 pid: 2119 ppid: 2114 banderas:0x00400208 [247.133905] Rastreo de llamadas: [247.136644] __switch_to+0x130/0x170 [ 247.140643] 14/0xa0c [247.144548] Schedule_preempt_disabled+0x88/ 0xf4 [ 247.149714] __mutex_lock_common+0x43c/0x750 [ 247.154496] mutex_lock_nested+0x5c/0x68 [ 247.158884] cfg80211_netdev_notifier_call+0x280/0x4e0 [cfg80211] [ 47.165769] raw_notifier_call_chain+0x4c/0x78 [ 247.170742] call_netdevice_notifiers_info+0x68/0xa4 [ 247.176305] __dev_close_many+0x7c /0x138 [ 247.180693] dev_close_many+0x7c/0x10c [ 247.184893] unregister_netdevice_many+0xfc/0x654 [ 247.190158] unregister_netdevice_queue+0xb4/0xe0 [ 247.195424] 11_unregister_wdev+0xa4/0x204 [cfg80211] [ 247.201816] cfg80211_unregister_wdev+0x20/0x2c [cfg80211] [ 247.208016 ] mwifiex_del_virtual_intf+0xc8/0x188 [mwifiex] [ 247.214174] mwifiex_uninit_sw+0x158/0x1b0 [mwifiex] [ 247.219747] mwifiex_remove_card+0x38/0xa0 [mwifiex] [ 247.225316 ] mwifiex_pcie_remove+0xd0/0xe0 [mwifiex_pcie] [ 247.231451] pci_device_remove+0x50/0xe0 [ 247.235849] device_release_driver_internal+0x110/0x1b0 [ 247.241701] driver_detach+0x5c/0x9c [ 247.245704] bus_remove_driver+0x84/0xb8 [ 247.250095] driver_unregister+0x3c/0x60 [ 2 47.254486] pci_unregister_driver+0x2c/0x90 [ 247.259267] cleanup_module+0x18/0xcdc [mwifiex_pcie ]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/mm: corrige el bloqueo en el fallo de ejecución del kernel. El kernel de powerpc no está preparado para manejar fallos de ejecución del kernel. Especialmente, la función is_exec_fault() devolverá 'false' cuando el kernel tome un fallo de ejecución, porque la verificación se basa en la lectura de current->thread.regs->trap que contiene la trampa del usuario. Por ejemplo, al provocar una prueba LKDTM EXEC_USERSPACE, current->thread.regs->trap se establece en SYSCALL trap (0xc00), y set_access_flags_filter() no ve el error cometido por el kernel como un error de ejecución. La confirmación d7df2443cd5f ("powerpc/mm: corregir errores de segmentación falsos en radix con autonuma") lo dejó claro y lo manejó correctamente. Pero más tarde, la confirmación d3ca587404b3 ("powerpc/mm: corregir informes de fallas de ejecución del kernel") eliminó ese manejo, introduciendo una prueba basada en error_code. Y aquí está el problema, porque en el 603 todos los bits superiores de SRR1 se borran cuando el controlador de errores de instrucción TLB sale a ISI. Hasta la confirmación cbd7e6ca0210 ("powerpc/fault: Evite la verificación pesada de search_exception_tables()"), un fallo de ejecución del kernel en una dirección de espacio de usuario se detectaba indirectamente por la falta de entrada para esa dirección en las tablas de excepción. Pero después de esa confirmación, el kernel depende principalmente de KUAP o del manejo de mm del núcleo para detectar accesos de usuarios incorrectos. Aquí el acceso no es incorrecto, por lo que mm lo maneja. Es un fallo menor porque PAGE_EXEC no está configurada, set_access_flags_filter() debería configurar PAGE_EXEC y listo. Pero como is_exec_fault() devuelve false como se explicó al principio, set_access_flags_filter() sale sin configurar el indicador PAGE_EXEC, lo que conduce a un fallo de ejecución menor para siempre. Como el kernel no está preparado para manejar tales fallos de ejecución, lo que hay que hacer es activar bad_kernel_fault() para cualquier fallo de ejecución tomado por el kernel, como estaba antes de la confirmación d3ca587404b3.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: corrige ejecucións entre las operaciones xattr_{set|get} y listxattr. UBIFS puede producir algunos problemas con las operaciones xattr_{set|get} y listxattr simultáneas, como fallas de aserción y corrupción de memoria. , valor xattr obsoleto [1]. Solucónelo importando un nuevo rw-lock en @ubifs_inode para serializar las operaciones de escritura en xattr, las operaciones de lectura simultáneas siguen siendo efectivas, al igual que ext4. [1] https://lore.kernel.org/linux-mtd/20200630130438.141649-1-houtao1@huawei.com

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udf: Se corrigió la desreferencia del puntero NULL en la función udf_symlink. En la función udf_symlink, a epos.bh se le asigna el valor devuelto por udf_tgetblk. La función udf_tgetblk está definida en udf/misc.c y devuelve el valor de la función sb_getblk que podría ser NULL. Luego, epos.bh se usa sin ninguna verificación, lo que provoca una posible desreferencia del puntero NULL cuando falla sb_getblk. Esta solución agrega una verificación para validar el valor de epos.bh.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/sched: evite la corrupción de datos. Espere a que se completen todas las dependencias de un trabajo antes de eliminarlo para evitar la corrupción de datos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atm: nicstar: corrige el posible use after free en nicstar_cleanup(). La ruta de eliminación de este módulo llama a del_timer(). Sin embargo, esa función no espera hasta que finalice el controlador del temporizador. Esto significa que es posible que el controlador del temporizador aún esté ejecutándose después de que haya finalizado la función de eliminación del controlador, lo que daría como resultado un use after free. Para solucionarlo, llame a del_timer_sync(), lo que garantiza que el controlador del temporizador haya finalizado y no pueda reprogramarse.