Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: state: fix out-of-limits read during lookup lookup and resize can run in parallel. El xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array. rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask; While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) { This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again). Solucione esto al precargar state_hmask y los punteros asociados. El reintento de seqlock xfrm_state_hash_generation asegurará que el puntero y el hmask sean consistentes. Los ayudantes existentes, como xfrm_dst_hash(), ahora no son seguros para el lado de RCU, agregue afirmaciones lockdep para documentar que solo son seguros para el lado de inserción. xfrm_state_lookup_byaddr() usa el bloqueo giratorio en lugar de RCU. AFAICS esto es un descuido de cuando la búsqueda de estado se convirtió a RCU, este bloqueo debe reemplazarse con RCU en un parche futuro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mailbox: th1520: Se corrige la corrupción de memoria debido a un tamaño de matriz incorrecto Las funciones th1520_mbox_suspend_noirq y th1520_mbox_resume_noirq tienen como objetivo guardar y restaurar los registros de máscara de interrupción en MBOX ICU0. Sin embargo, la matriz utilizada para almacenar estos registros tenía un tamaño incorrecto, lo que provocaba una corrupción de memoria al acceder a los cuatro registros. Esta confirmación corrige el tamaño de la matriz para acomodar los cuatro registros de máscara de interrupción, lo que evita la corrupción de memoria durante las operaciones de suspensión y reanudación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rdma/cxgb4: Evitar un posible desbordamiento de enteros en 32 bits La variable "gl->tot_len" está controlada por el usuario. Proviene de process_responses(). En sistemas de 32 bits, la adición "gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)" podría tener un error de envoltura de enteros. Utilice size_add() para evitar esto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memcg: corrige bloqueo suave en el proceso OOM Se encontró un problema de bloqueo suave en el producto con aproximadamente 56 000 tareas en el cgroup OOM, las estaba atravesando cuando se activó el bloqueo suave. watchdog: ERROR: bloqueo suave: ¡CPU n.° 2 bloqueada durante 23 s! [Hilo de VM:1503066] CPU: 2 PID: 1503066 Comm: Hilo de VM Kdump: cargado Contaminado: G Nombre del hardware: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:console_unlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 00000000000000080 R11: 00000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: vprintk_emit+0x193/0x280 printk+0x52/0x6e dump_task+0x114/0x130 mem_cgroup_scan_tasks+0x76/0x100 dump_header+0x1fe/0x210 oom_kill_process+0xd1/0x100 out_of_memory+0x125/0x570 mem_cgroup_out_of_memory+0xb5/0xd0 try_charge+0x720/0x770 mem_cgroup_try_charge+0x86/0x180 mem_cgroup_try_charge_delay+0x1c/0x40 do_anonymous_page+0xb5/0x390 handle_mm_fault+0xc4/0x1f0 Esto se debe a que hay miles de procesos en el grupo de control OOM y lleva mucho tiempo recorrerlos todos. Como resultado, esto conduce a un bloqueo suave en el proceso OOM. Para solucionar este problema, llame a "cond_resched" en la función "mem_cgroup_scan_tasks" cada 1000 iteraciones. Para OOM global, llame a "touch_softlockup_watchdog" cada 1000 iteraciones para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: imx-jpeg: Se corrige la posible desreferencia del puntero de error en detach_pm() El problema está en la primera línea: if (jpeg->pd_dev[i] && !pm_runtime_suspended(jpeg->pd_dev[i])) Si jpeg->pd_dev[i] es un puntero de error, entonces pasarlo a pm_runtime_suspended() provocará un Oops. Las otras condiciones comprueban tanto los punteros de error como NULL, pero sería más claro usar la comprobación IS_ERR_OR_NULL() para eso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: lidiar con la ejecución entre el cambio de dirección del socket UDP y el rehash Si un socket UDP cambia su dirección local mientras recibe datagramas, como resultado de connect(), hay un período durante el cual una operación de búsqueda podría fallar en encontrarlo, después de que se cambie la dirección pero antes de que se actualicen el hash secundario (puerto y dirección) y el hash de cuatro tuplas (puertos y direcciones locales y remotos). Las cadenas de hash secundarias fueron introducidas por el commit 30fff9231fad ("udp: optimización de bind()") y, como resultado, se necesitó una operación de rehash para hacer que un socket enlazado sea accesible nuevamente después de un connect(). Esta operación fue introducida por el commit 719f835853a9 ("udp: agregar rehash en connect()") que, sin embargo, no es una solución completa: el socket se encontrará una vez que se complete el rehash, pero no mientras esté pendiente. Esto se nota con un servidor socat(1) en modo UDP4-LISTEN y un cliente que le envía datagramas. Después de que el servidor recibe el primer datagrama (cf. _xioopen_ipdgram_listen()), emite un connect() a la dirección del remitente, para establecer un flujo dirigido. Ahora, si el cliente, que se ejecuta en un subproceso de CPU diferente, envía un datagrama (posterior) mientras el socket del servidor cambia su dirección, pero aún no se vuelve a procesar, esto dará como resultado una búsqueda fallida y un error de puerto inalcanzable entregado al cliente, como se desprende del siguiente reproductor: LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4)) dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in while :; do taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.1 || sleep 1 taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null done donde el cliente eventualmente obtendrá ECONNREFUSED en un write() (normalmente el segundo o tercero de una iteración dada): 2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection denied Este problema se observó por primera vez como una falla poco frecuente en las pruebas de Podman que verificaban la funcionalidad de UDP mientras se usaba pasta(1) para conectar el espacio de nombres de red del contenedor, lo que nos lleva a un reproductor con el error de búsqueda que resulta en un paquete ICMP en un dispositivo tap: LOCAL_ADDR="$(ip -j -4 addr show|jq -rM '.[] | .addr_info[0] | select(.scope == "global").local')" while :; do ./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.2 || sleep 1 socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null wait cmp tmp.in tmp.out done Once this fails: tmp.in tmp.out differ: char 8193, line 29 we can finally have a look at what's going on: $ tshark -r pasta.pcap 1 0.000000 :: ? ff02::16 ICMPv6 110 Multicast Listener Report Message v2 2 0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 3 0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 4 0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 5 0.168827 c6:47:05:8d:dc:04 ? Broadcast ARP 42 Who has 88.198.0.161? Tell 88.198.0.164 6 0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55 7 0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 8 0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable) 9 0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 10 0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 11 0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096 12 0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0 On the third datagram received, the network namespace of the container initiates an ARP lookup to deliver the ICMP message. In another variant of this reproducer, starting the client with: strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp---truncada---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: realizar una depuración de folio adecuada cuando falla run_delalloc_nocow() [ERROR] Con CONFIG_DEBUG_VM establecido, el caso de prueba genérico/476 tiene alguna posibilidad de bloquearse con el siguiente VM_BUG_ON_FOLIO(): BTRFS error (device dm-3): cow_file_range failed, start 1146880 end 1253375 len 106496 ret -28 BTRFS error (device dm-3): run_delalloc_nocow failed, start 1146880 end 1253375 len 106496 ret -28 page: refcount:4 mapcount:0 mapping:00000000592787cc index:0x12 pfn:0x10664 aops:btrfs_aops [btrfs] ino:101 dentry name(?):"f1774" flags: 0x2fffff80004028(uptodate|lru|private|node=0|zone=2|lastcpupid=0xfffff) page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio)) ------------[ cut here ]------------ kernel BUG at mm/page-writeback.c:2992! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 2 UID: 0 PID: 3943513 Comm: kworker/u24:15 Tainted: G OE 6.12.0-rc7-custom+ #87 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : folio_clear_dirty_for_io+0x128/0x258 lr : folio_clear_dirty_for_io+0x128/0x258 Call trace: folio_clear_dirty_for_io+0x128/0x258 btrfs_folio_clamp_clear_dirty+0x80/0xd0 [btrfs] __process_folios_contig+0x154/0x268 [btrfs] extent_clear_unlock_delalloc+0x5c/0x80 [btrfs] run_delalloc_nocow+0x5f8/0x760 [btrfs] btrfs_run_delalloc_range+0xa8/0x220 [btrfs] writepage_delalloc+0x230/0x4c8 [btrfs] extent_writepage+0xb8/0x358 [btrfs] extent_write_cache_pages+0x21c/0x4e8 [btrfs] btrfs_writepages+0x94/0x150 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x88/0xc8 start_delalloc_inodes+0x178/0x3a8 [btrfs] btrfs_start_delalloc_roots+0x174/0x280 [btrfs] shrink_delalloc+0x114/0x280 [btrfs] flush_space+0x250/0x2f8 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x164/0x408 worker_thread+0x25c/0x388 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: 910a8021 a90363f7 a9046bf9 94012379 (d4210000) ---[ end trace 0000000000000000 ]--- [CAUSE] The first two lines of extra debug messages show the problem is caused by the error handling of run_delalloc_nocow(). E.g. we have the following dirtied range (4K blocksize 4K page size): 0 16K 32K |//////////////////////////////////////| | Pre-allocated | And the range [0, 16K) has a preallocated extent. - Enter run_delalloc_nocow() for range [0, 16K) Which found range [0, 16K) is preallocated, can do the proper NOCOW write. - Enter fallback_to_fow() for range [16K, 32K) Since the range [16K, 32K) is not backed by preallocated extent, we have to go COW. - cow_file_range() failed for range [16K, 32K) So cow_file_range() will do the clean up by clearing folio dirty, unlock the folios. Now the folios in range [16K, 32K) is unlocked. - Enter extent_clear_unlock_delalloc() from run_delalloc_nocow() Which is called with PAGE_START_WRITEBACK to start page writeback. Pero los folios solo se pueden marcar como escritura diferida cuando están correctamente bloqueados, por lo que esto activó VM_BUG_ON_FOLIO(). Además, hay otro error oculto pero común: run_delalloc_nocow() no borra las banderas de folio sucio en su ruta de gestión de errores. Este es el error común compartido entre run_delalloc_nocow() y cow_file_range(). [FIX] - Limpiar el folio sucio para el rango [@start, @cur_offset) Introducir un ayudante, cleanup_dirty_folios(), que encontrará y bloqueará el folio en el rango, limpiará la bandera sucia y comenzará/finalizará la escritura diferida, con el manejo adicional para @locked_folio. - Introducir un ayudante para limpiar el folio sucio, iniciar y finalizar la escritura diferida - Introducir un ayudante para registrar el último final del rango COW fallido Esto es para rastrear qué rango debemos omitir, para evitar el doble desbloqueo. - Omitir el rango COW fallido para el e ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtc: tps6594: Corregir desbordamiento de enteros en sistemas de 32 bits El problema es que esto se multiplica en tps6594_rtc_set_offset() tmp = offset * TICKS_PER_HOUR; La variable "tmp" es un s64 pero "offset" es un long en el rango (-277774)-277774. En sistemas de 32 bits, un long puede contener números de hasta aproximadamente dos mil millones. El número de TICKS_PER_HOUR es realmente grande, (32768 * 3600) o aproximadamente cien millones. Cuando comienza a multiplicar por cien millones, no tarda mucho en desbordar la marca de dos mil millones. Probablemente, la forma más segura de solucionar esto es cambiar el tipo de TICKS_PER_HOUR a long long porque es un número muy grande.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: realiza una limpieza de folio adecuada cuando falla cow_file_range() [ERROR] Al probar con la corrección de COW marcada como BUG_ON() (this is involved with the new pin_user_pages*() change, which should not result new out-of-band dirty pages), I hit a crash triggered by the BUG_ON() from hitting COW fixup path. This BUG_ON() happens just after a failed btrfs_run_delalloc_range(): BTRFS error (device dm-2): failed to run delalloc range, root 348 ino 405 folio 65536 submit_bitmap 6-15 start 90112 len 106496: -28 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1444! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 UID: 0 PID: 434621 Comm: kworker/u24:8 Tainted: G OE 6.12.0-rc7-custom+ #86 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : extent_writepage_io+0x2d4/0x308 [btrfs] lr : extent_writepage_io+0x2d4/0x308 [btrfs] Call trace: extent_writepage_io+0x2d4/0x308 [btrfs] extent_writepage+0x218/0x330 [btrfs] extent_write_cache_pages+0x1d4/0x4b0 [btrfs] btrfs_writepages+0x94/0x150 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x88/0xc8 start_delalloc_inodes+0x180/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x174/0x280 [btrfs] shrink_delalloc+0x114/0x280 [btrfs] flush_space+0x250/0x2f8 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x164/0x408 worker_thread+0x25c/0x388 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: aa1403e1 9402f3ef aa1403e0 9402f36f (d4210000) ---[ end trace 0000000000000000 ]--- [CAUSE] That failure is mostly from cow_file_range(), where we can hit -ENOSPC. Although the -ENOSPC is already a bug related to our space reservation code, let's just focus on the error handling. For example, we have the following dirty range [0, 64K) of an inode, with 4K sector size and 4K page size: 0 16K 32K 48K 64K |///////////////////////////////////////| |#######################################| Where |///| means page are still dirty, and |###| means the extent io tree has EXTENT_DELALLOC flag. - Enter extent_writepage() for page 0 - Enter btrfs_run_delalloc_range() for range [0, 64K) - Enter cow_file_range() for range [0, 64K) - Function btrfs_reserve_extent() only reserved one 16K extent So we created extent map and ordered extent for range [0, 16K) 0 16K 32K 48K 64K |////////|//////////////////////////////| |<- OE ->|##############################| And range [0, 16K) has its delalloc flag cleared. But since we haven't yet submit any bio, involved 4 pages are still dirty. - Function btrfs_reserve_extent() returns with -ENOSPC Now we have to run error cleanup, which will clear all EXTENT_DELALLOC* flags and clear the dirty flags for the remaining ranges: 0 16K 32K 48K 64K |////////| | | | | Note that range [0, 16K) still has its pages dirty. - Some time later, writeback is triggered again for the range [0, 16K) since the page range still has dirty flags. - btrfs_run_delalloc_range() will do nothing because there is no EXTENT_DELALLOC flag. - extent_writepage_io() finds page 0 has no ordered flag Which falls into the COW fixup path, triggering the BUG_ON(). Desafortunadamente, este error de gestión de errores se remonta a la introducción de btrfs. Afortunadamente, con el abuso de la corrección de COW, al menos no bloqueará el kernel. [SOLUCIÓN] En lugar de desbloquear inmediatamente la extensión y los folios, mantenemos la extensión y los folios bloqueados hasta que se produzca un error o hasta que finalice todo el rango de deslocalización. Cuando finaliza todo el rango de deslocalización sin errores, simplemente desbloqueamos todo el rango con PAGE_SET_ORDERED (y PAGE_UNLOCK para los casos !keep_locked) ---truncado---

Razón rechazado: esta identificación de CVE ha sido rechazada o retirada por su autoridad de numeración de CVE.

Razón rechazado: ** RECHAZADA ** No use este número de candidato. Razón: este candidato fue emitido por error. Notas: Todas las referencias y descripciones en este candidato se han eliminado para evitar el uso accidental.

Se descubrió que TL-WR845N(UN)_V4_200909 y TL-WR845N(UN)_V4_190219 contienen una contraseña codificada para la cuenta raíz que se puede obtener mediante un ataque de fuerza bruta.