Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fsnotify: no generar eventos ACCESS/MODIFY en el hijo para archivos especiales<br /> <br /> inotify/fanotify no permiten a los usuarios sin acceso de lectura a un archivo suscribirse a eventos (p. ej., IN_ACCESS/IN_MODIFY), pero sí permiten al mismo usuario suscribirse para observar eventos en los hijos cuando el usuario tiene acceso al directorio padre (p. ej., /dev).<br /> <br /> Los usuarios sin acceso de lectura a un archivo pero con acceso de lectura a su directorio padre aún pueden hacer stat al archivo y ver si fue accedido/modificado a través de un cambio en atime/mtime.<br /> <br /> Lo mismo no es cierto para archivos especiales (p. ej., /dev/null). Los usuarios generalmente no observarán cambios en atime/mtime cuando otros usuarios leen/escriben en archivos especiales, solo cuando alguien establece atime/mtime a través de utimensat().<br /> <br /> Alinear los eventos de fsnotify con este comportamiento de stat y no generar eventos ACCESS/MODIFY a los observadores padre en la lectura/escritura de archivos especiales. Los eventos aún se generan a los observadores padre en utimensat(). Esto cierra algunos canales laterales que podrían ser posiblemente utilizados para la exfiltración de información [1].<br /> <br /> [1] https://snee.la/pdf/pubs/file-notification-attacks.pdf

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/handshake: las cancelaciones duplicadas de handshake fugan el socket<br /> <br /> Cuando una solicitud de handshake es cancelada, es eliminada de la lista handshake_net-&amp;gt;hn_requests, pero aún está presente en la handshake_rhashtbl hasta que es destruida.<br /> <br /> Si llega una segunda solicitud de cancelación para la misma solicitud de handshake, entonces remove_pending() devolverá falso... y asumiendo que HANDSHAKE_F_REQ_COMPLETED no está establecido en req-&amp;gt;hr_flags, continuaremos procesando a través de la etiqueta out_true, donde ponemos otra referencia en el sock y ocurre un desbordamiento negativo del contador de referencias.<br /> <br /> Esto puede ocurrir por ejemplo si un handshake agota el tiempo de espera, particularmente si el cliente SUNRPC envía la sonda AUTH_TLS al servidor pero no la sigue con el ClientHello debido a un problema con tlshd. Cuando se alcanza el tiempo de espera en el servidor, el servidor enviará un FIN, lo que activa una solicitud de cancelación a través de xs_reset_transport(). Cuando se alcanza el tiempo de espera en el cliente, ocurre otra solicitud de cancelación a través de xs_tls_handshake_sync().<br /> <br /> Añadir un test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED) en la ruta de cancelación pendiente para que las cancelaciones duplicadas puedan ser detectadas.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/hsr: corrección de desreferencia de puntero NULL en prp_get_untagged_frame()<br /> <br /> prp_get_untagged_frame() llama a __pskb_copy() para crear frame-&amp;gt;skb_std, pero no comprueba si la asignación falló. Si __pskb_copy() devuelve NULL, se llama a skb_clone() con un puntero NULL, lo que provoca un fallo:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]<br /> CPU: 0 UID: 0 PID: 5625 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:skb_clone+0xd7/0x3a0 net/core/skbuff.c:2041<br /> Code: 03 42 80 3c 20 00 74 08 4c 89 f7 e8 23 29 05 f9 49 83 3e 00 0f 85 a0 01 00 00 e8 94 dd 9d f8 48 8d 6b 7e 49 89 ee 49 c1 ee 03 &amp;lt;43&amp;gt; 0f b6 04 26 84 c0 0f 85 d1 01 00 00 44 0f b6 7d 00 41 83 e7 0c<br /> RSP: 0018:ffffc9000d00f200 EFLAGS: 00010207<br /> RAX: ffffffff892235a1 RBX: 0000000000000000 RCX: ffff88803372a480<br /> RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000000<br /> RBP: 000000000000007e R08: ffffffff8f7d0f77 R09: 1ffffffff1efa1ee<br /> R10: dffffc0000000000 R11: fffffbfff1efa1ef R12: dffffc0000000000<br /> R13: 0000000000000820 R14: 000000000000000f R15: ffff88805144cc00<br /> FS: 0000555557f6d500(0000) GS:ffff88808d72f000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000555581d35808 CR3: 000000005040e000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> hsr_forward_do net/hsr/hsr_forward.c:-1 [inline]<br /> hsr_forward_skb+0x1013/0x2860 net/hsr/hsr_forward.c:741<br /> hsr_handle_frame+0x6ce/0xa70 net/hsr/hsr_slave.c:84<br /> __netif_receive_skb_core+0x10b9/0x4380 net/core/dev.c:5966<br /> __netif_receive_skb_one_core net/core/dev.c:6077 [inline]<br /> __netif_receive_skb+0x72/0x380 net/core/dev.c:6192<br /> netif_receive_skb_internal net/core/dev.c:6278 [inline]<br /> netif_receive_skb+0x1cb/0x790 net/core/dev.c:6337<br /> tun_rx_batched+0x1b9/0x730 drivers/net/tun.c:1485<br /> tun_get_user+0x2b65/0x3e90 drivers/net/tun.c:1953<br /> tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1999<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0x5c9/0xb30 fs/read_write.c:686<br /> ksys_write+0x145/0x250 fs/read_write.c:738<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f0449f8e1ff<br /> Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 f9 92 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 &amp;lt;48&amp;gt; 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 4c 93 02 00 48<br /> RSP: 002b:00007ffd7ad94c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 00007f044a1e5fa0 RCX: 00007f0449f8e1ff<br /> RDX: 000000000000003e RSI: 0000200000000500 RDI: 00000000000000c8<br /> RBP: 00007ffd7ad94d20 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 000000000000003e R11: 0000000000000293 R12: 0000000000000001<br /> R13: 00007f044a1e5fa0 R14: 00007f044a1e5fa0 R15: 0000000000000003<br /> <br /> <br /> Añadir una comprobación de NULL inmediatamente después de __pskb_copy() para manejar los fallos de asignación de forma elegante.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> Input: ti_am335x_tsc - corrige error de uno en la validación de &amp;#39;wire_order&amp;#39;<br /> <br /> La validación actual &amp;#39;wire_order[i] &amp;gt; ARRAY_SIZE(config_pins)&amp;#39; permite que wire_order[i] sea igual a ARRAY_SIZE(config_pins), lo que causa acceso fuera de límites cuando se usa como índice en &amp;#39;config_pins[wire_order[i]]&amp;#39;.<br /> <br /> Dado que config_pins tiene 4 elementos (índices 0-3), el rango válido para wire_order debería ser 0-3. Corrige el error de uno usando &amp;#39;&amp;gt;=&amp;#39; en lugar de &amp;#39;&amp;gt;&amp;#39; en la comprobación de validación.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t log conflicting inode if it&amp;#39;s a dir moved in the current transaction<br /> <br /> We can&amp;#39;t log a conflicting inode if it&amp;#39;s a directory and it was moved<br /> from one parent directory to another parent directory in the current<br /> transaction, as this can result an attempt to have a directory with<br /> two hard links during log replay, one for the old parent directory and<br /> another for the new parent directory.<br /> <br /> The following scenario triggers that issue:<br /> <br /> 1) We have directories "dir1" and "dir2" created in a past transaction.<br /> Directory "dir1" has inode A as its parent directory;<br /> <br /> 2) We move "dir1" to some other directory;<br /> <br /> 3) We create a file with the name "dir1" in directory inode A;<br /> <br /> 4) We fsync the new file. This results in logging the inode of the new file<br /> and the inode for the directory "dir1" that was previously moved in the<br /> current transaction. So the log tree has the INODE_REF item for the<br /> new location of "dir1";<br /> <br /> 5) We move the new file to some other directory. This results in updating<br /> the log tree to included the new INODE_REF for the new location of the<br /> file and removes the INODE_REF for the old location. This happens<br /> during the rename when we call btrfs_log_new_name();<br /> <br /> 6) We fsync the file, and that persists the log tree changes done in the<br /> previous step (btrfs_log_new_name() only updates the log tree in<br /> memory);<br /> <br /> 7) We have a power failure;<br /> <br /> 8) Next time the fs is mounted, log replay happens and when processing<br /> the inode for directory "dir1" we find a new INODE_REF and add that<br /> link, but we don&amp;#39;t remove the old link of the inode since we have<br /> not logged the old parent directory of the directory inode "dir1".<br /> <br /> As a result after log replay finishes when we trigger writeback of the<br /> subvolume tree&amp;#39;s extent buffers, the tree check will detect that we have<br /> a directory a hard link count of 2 and we get a mount failure.<br /> The errors and stack traces reported in dmesg/syslog are like this:<br /> <br /> [ 3845.729764] BTRFS info (device dm-0): start tree-log replay<br /> [ 3845.730304] page: refcount:3 mapcount:0 mapping:000000005c8a3027 index:0x1d00 pfn:0x11510c<br /> [ 3845.731236] memcg:ffff9264c02f4e00<br /> [ 3845.731751] aops:btree_aops [btrfs] ino:1<br /> [ 3845.732300] flags: 0x17fffc00000400a(uptodate|private|writeback|node=0|zone=2|lastcpupid=0x1ffff)<br /> [ 3845.733346] raw: 017fffc00000400a 0000000000000000 dead000000000122 ffff9264d978aea8<br /> [ 3845.734265] raw: 0000000000001d00 ffff92650e6d4738 00000003ffffffff ffff9264c02f4e00<br /> [ 3845.735305] page dumped because: eb page dump<br /> [ 3845.735981] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=6 ino=257, invalid nlink: has 2 expect no more than 1 for dir<br /> [ 3845.737786] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14881 owner 5<br /> [ 3845.737789] BTRFS info (device dm-0): refs 4 lock_owner 0 current 30701<br /> [ 3845.737792] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160<br /> [ 3845.737794] inode generation 3 transid 9 size 16 nbytes 16384<br /> [ 3845.737795] block group 0 mode 40755 links 1 uid 0 gid 0<br /> [ 3845.737797] rdev 0 sequence 2 flags 0x0<br /> [ 3845.737798] atime 1764259517.0<br /> [ 3845.737800] ctime 1764259517.572889464<br /> [ 3845.737801] mtime 1764259517.572889464<br /> [ 3845.737802] otime 1764259517.0<br /> [ 3845.737803] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12<br /> [ 3845.737805] index 0 name_len 2<br /> [ 3845.737807] item 2 key (256 DIR_ITEM 2363071922) itemoff 16077 itemsize 34<br /> [ 3845.737808] location key (257 1 0) type 2<br /> [ 3845.737810] transid 9 data_len 0 name_len 4<br /> [ 3845.737811] item 3 key (256 DIR_ITEM 2676584006) itemoff 16043 itemsize 34<br /> [ 3845.737813] location key (258 1 0) type 2<br /> [ 3845.737814] transid 9 data_len 0 name_len 4<br /> [ 3845.737815] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34<br /> [ 3845.737816] location key (257 1 0) type 2<br /> [<br /> ---truncated---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/mlx5e: Evitar desregistrar PSP dos veces<br /> <br /> PSP se desregistra dos veces en:<br /> _mlx5e_remove -&amp;gt; mlx5e_psp_unregister<br /> mlx5e_nic_cleanup -&amp;gt; mlx5e_psp_unregister<br /> <br /> Esto conduce a un refcount underflow en algunas condiciones:<br /> ------------[ corte aquí ]------------<br /> refcount_t: underflow; uso después de liberación.<br /> ADVERTENCIA: CPU: 2 PID: 1694 en lib/refcount.c:28 refcount_warn_saturate+0xd8/0xe0<br /> [...]<br /> mlx5e_psp_unregister+0x26/0x50 [mlx5_core]<br /> mlx5e_nic_cleanup+0x26/0x90 [mlx5_core]<br /> mlx5e_remove+0xe6/0x1f0 [mlx5_core]<br /> auxiliary_bus_remove+0x18/0x30<br /> device_release_driver_internal+0x194/0x1f0<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x159/0x3c0<br /> mlx5_rescan_drivers_locked+0xbc/0x2a0 [mlx5_core]<br /> [...]<br /> <br /> No eliminar directamente psp de la ruta _mlx5e_remove, la limpieza de PSP ocurre como parte de la limpieza del perfil.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> sched/deadline: solo establecer free_cpus para runqueues en línea<br /> <br /> El commit 16b269436b72 (&amp;#39;sched/deadline: Modificar cpudl::free_cpus para reflejar rd-&amp;gt;online&amp;#39;) introdujo las funciones cpudl_set/clear_freecpu para permitir que la máscara cpu_dl::free_cpus fuera manipulada por las devoluciones de llamada rq_on/offline de la clase de planificador de plazo para que la máscara también reflejara este estado.<br /> <br /> El commit 9659e1eeee28 (&amp;#39;sched/deadline: Eliminar cpu_active_mask de cpudl_find()&amp;#39;) eliminó la comprobación de la cpu_active_mask para ahorrar algo de procesamiento bajo la premisa de que la máscara cpudl::free_cpus ya reflejaba el estado en línea del runqueue.<br /> <br /> Desafortunadamente, hay casos en los que es posible que la función cpudl_clear establezca el bit free_cpus para una CPU cuando el runqueue de plazo está fuera de línea. Cuando esto ocurre mientras una CPU está conectada al dominio raíz predeterminado, el indicador puede retener el estado incorrecto después de que la CPU haya sido desconectada. Más tarde, una CPU diferente que está en transición a través del dominio raíz predeterminado puede empujar una tarea de plazo a la CPU apagada cuando cpudl_find ve que su bit free_cpus está establecido. Si esto sucede, la tarea no tendrá la oportunidad de ejecutarse.<br /> <br /> Un ejemplo se describe aquí:<br /> https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.com<br /> <br /> Otro ocurre cuando la última tarea de plazo es migrada de una CPU que tiene un runqueue fuera de línea. El miembro dequeue_task de la clase de planificador de plazo eventualmente llamará a cpudl_clear y establecerá el bit free_cpus para la CPU.<br /> <br /> Este commit modifica la función cpudl_clear para que sea consciente del estado en línea del runqueue de plazo para que la máscara free_cpus pueda ser actualizada apropiadamente.<br /> <br /> Ya no es necesario gestionar la máscara fuera de las funciones cpudl_set/clear, por lo que las funciones cpudl_set/clear_freecpu son eliminadas. Además, dado que la máscara free_cpus ahora solo se actualiza bajo el bloqueo cpudl, el código fue cambiado para usar las funciones no atómicas __cpumask.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> usb: phy: fsl-usb: Corrección de uso después de liberación en trabajo retrasado durante la eliminación del dispositivo<br /> <br /> El elemento de trabajo retrasado otg_event se inicializa en fsl_otg_conf() y se programa bajo dos condiciones:<br /> 1. Cuando un controlador de host se enlaza al controlador OTG.<br /> 2. Cuando el estado del pin ID USB cambia (inserción/extracción de cable).<br /> <br /> Una condición de carrera ocurre cuando el dispositivo es eliminado a través de fsl_otg_remove(): la instancia fsl_otg puede ser liberada mientras el trabajo retrasado aún está pendiente o ejecutándose. Esto lleva a un uso después de liberación cuando la función de trabajo fsl_otg_event() accede a la memoria ya liberada.<br /> <br /> El escenario problemático:<br /> <br /> (hilo de desvinculación) | (trabajo retrasado)<br /> fsl_otg_remove() |<br /> kfree(fsl_otg_dev) //FREE| fsl_otg_event()<br /> | og = container_of(...) //USE<br /> | og-&amp;gt; //USE<br /> <br /> Solucione esto llamando a disable_delayed_work_sync() en fsl_otg_remove() antes de desasignar la estructura fsl_otg. Esto asegura que el trabajo retrasado sea cancelado correctamente y complete su ejecución antes de la desasignación de memoria.<br /> <br /> Este error fue identificado a través de análisis estático.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: target: Restablecer el puntero t_task_cdb en caso de error<br /> <br /> Si la asignación de cmd-&amp;gt;t_task_cdb falla, permanece NULL pero luego es desreferenciado en la ruta de &amp;#39;error&amp;#39;.<br /> <br /> En caso de error, restablecer el valor NULL de t_task_cdb para que apunte al búfer predeterminado de tamaño fijo.<br /> <br /> Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> hfsplus: Verificar el modo del inodo al cargar desde el disco<br /> <br /> syzbot está informando que los bits S_IFMT de inode-&amp;gt;i_mode pueden volverse inválidos cuando los bits S_IFMT del campo &amp;#39;mode&amp;#39; de 16 bits cargado desde el disco están corruptos.<br /> <br /> Según [1], el campo de permisos fue tratado como reservado en Mac OS 8 y 9. Según [2], el campo reservado fue inicializado explícitamente con 0, y ese campo debe permanecer en 0 mientras esté reservado. Por lo tanto, cuando el campo &amp;#39;mode&amp;#39; no es 0 (es decir, ya no está reservado), el archivo debe ser S_IFDIR si dir == 1, y el archivo debe ser uno de S_IFREG/S_IFLNK/S_IFCHR/S_IFBLK/S_IFIFO/S_IFSOCK si dir == 0.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> inet: frags: vaciar skbs pendientes en fqdir_pre_exit()<br /> <br /> Hemos estado viendo interbloqueos ocasionales en pernet_ops_rwsem desde septiembre en NIPA. La tarea atascada era usualmente modprobe (a menudo cargando un controlador como ipvlan), intentando tomar el bloqueo como un Escritor. lockdep no rastrea lectores para rwsems por lo que la lectura no era obvia de los informes.<br /> <br /> En una inspección más cercana, el Lector que mantenía el bloqueo era conntrack haciendo un bucle para siempre en nf_conntrack_cleanup_net_list(). Basado en la experiencia pasada con fallos ocasionales de NIPA, revisé las pruebas que se ejecutan antes del fallo y noté que el fallo sigue a ip_defrag.sh. Una bandera roja inmediata. Revisar a fondo las colas de (des)fragmentación revela skbs que permanecen, manteniendo referencias de conntrack.<br /> <br /> El problema es que, dado que conntrack depende de nf_defrag_ipv6, nf_defrag_ipv6 se cargará primero. Dado que nf_defrag_ipv6 se carga primero, sus hooks de salida de netns se ejecutan _después_ del hook de salida de netns de conntrack.<br /> <br /> Vaciar todos los SKBs de la cola de fragmentos durante fqdir_pre_exit() para liberar referencias de conntrack antes de que se ejecute la limpieza de conntrack. También vaciar las colas en los manejadores de expiración del temporizador cuando descubren que fqdir-&amp;gt;dead está establecido, en caso de que un paquete se cuele mientras estamos ejecutando el vaciado de pre_exit.<br /> <br /> El commit bajo Fixes no es exactamente el culpable, pero creo que anteriormente el disparo del temporizador eventualmente desbloquearía el conntrack en bucle.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> f2fs: corrige el valor de retorno de f2fs_recover_fsync_data()<br /> <br /> Con los siguientes scripts, se activará un pánico en f2fs:<br /> <br /> mkfs.f2fs -f /dev/vdd<br /> mount /dev/vdd /mnt/f2fs<br /> touch /mnt/f2fs/foo<br /> sync<br /> echo 111 &amp;gt;&amp;gt; /mnt/f2fs/foo<br /> f2fs_io fsync /mnt/f2fs/foo<br /> f2fs_io shutdown 2 /mnt/f2fs<br /> umount /mnt/f2fs<br /> mount -o ro,norecovery /dev/vdd /mnt/f2fs<br /> or<br /> mount -o ro,disable_roll_forward /dev/vdd /mnt/f2fs<br /> <br /> F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 0<br /> F2FS-fs (vdd): Mounted with checkpoint version = 7f5c361f<br /> F2FS-fs (vdd): Stopped filesystem due to reason: 0<br /> F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 1<br /> Filesystem f2fs get_tree() didn&amp;#39;t set fc-&amp;gt;root, returned 1<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/super.c:1761!<br /> Oops: invalid opcode: 0000 [#1] SMP PTI<br /> CPU: 3 UID: 0 PID: 722 Comm: mount Not tainted 6.18.0-rc2+ #721 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:vfs_get_tree.cold+0x18/0x1a<br /> Call Trace:<br /> <br /> fc_mount+0x13/0xa0<br /> path_mount+0x34e/0xc50<br /> __x64_sys_mount+0x121/0x150<br /> do_syscall_64+0x84/0x800<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fa6cc126cfe<br /> <br /> La causa raíz es que omitimos manejar el número de error devuelto por f2fs_recover_fsync_data() al montar la imagen con la opción de montaje ro,norecovery o ro,disable_roll_forward, lo que resulta en la devolución de un número de error positivo a vfs_get_tree(), se corrige.