Vulnerabilidades

Se descubrió que Tenda AX-3 v16.03.12.10_CN contenía un desbordamiento de pila en el parámetro wanSpeed2 de la función fromAdvSetMacMtuWan. Esta vulnerabilidad permite a los atacantes causar una denegación de servicio (DoS) mediante una solicitud manipulada.

Se descubrió que Tenda AX-3 v16.03.12.10_CN contenía un desbordamiento de pila en el parámetro wanMTU2 de la función fromAdvSetMacMtuWan. Esta vulnerabilidad permite a los atacantes causar una Denegación de Servicio (DoS) a través de una solicitud especialmente diseñada.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: hns3: usando los num_tqps en el controlador vf para solicitar recursos<br /> <br /> Actualmente, hdev-&amp;gt;htqp se asigna usando hdev-&amp;gt;num_tqps, y kinfo-&amp;gt;tqp se asigna usando kinfo-&amp;gt;num_tqps. Sin embargo, kinfo-&amp;gt;num_tqps se establece en min(new_tqps, hdev-&amp;gt;num_tqps); Por lo tanto, kinfo-&amp;gt;num_tqps puede ser menor que hdev-&amp;gt;num_tqps, lo que provoca que algunos hdev-&amp;gt;htqp[i] permanezcan sin inicializar en hclgevf_knic_setup().<br /> <br /> Así, este parche asigna hdev-&amp;gt;htqp y kinfo-&amp;gt;tqp usando hdev-&amp;gt;num_tqps, asegurando que las longitudes de hdev-&amp;gt;htqp y kinfo-&amp;gt;tqp sean consistentes y que todos los elementos se inicialicen correctamente.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid potential deadlock<br /> <br /> As Jiaming Zhang and syzbot reported, there is potential deadlock in<br /> f2fs as below:<br /> <br /> Chain exists of:<br /> &amp;sbi-&gt;cp_rwsem --&gt; fs_reclaim --&gt; sb_internal#2<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> rlock(sb_internal#2);<br /> lock(fs_reclaim);<br /> lock(sb_internal#2);<br /> rlock(&amp;sbi-&gt;cp_rwsem);<br /> <br /> *** DEADLOCK ***<br /> <br /> 3 locks held by kswapd0/73:<br /> #0: ffffffff8e247a40 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat mm/vmscan.c:7015 [inline]<br /> #0: ffffffff8e247a40 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x951/0x2800 mm/vmscan.c:7389<br /> #1: ffff8880118400e0 (&amp;type-&gt;s_umount_key#50){.+.+}-{4:4}, at: super_trylock_shared fs/super.c:562 [inline]<br /> #1: ffff8880118400e0 (&amp;type-&gt;s_umount_key#50){.+.+}-{4:4}, at: super_cache_scan+0x91/0x4b0 fs/super.c:197<br /> #2: ffff888011840610 (sb_internal#2){.+.+}-{0:0}, at: f2fs_evict_inode+0x8d9/0x1b60 fs/f2fs/inode.c:890<br /> <br /> stack backtrace:<br /> CPU: 0 UID: 0 PID: 73 Comm: kswapd0 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 /> Call Trace:<br /> <br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> print_circular_bug+0x2ee/0x310 kernel/locking/lockdep.c:2043<br /> check_noncircular+0x134/0x160 kernel/locking/lockdep.c:2175<br /> check_prev_add kernel/locking/lockdep.c:3165 [inline]<br /> check_prevs_add kernel/locking/lockdep.c:3284 [inline]<br /> validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3908<br /> __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5237<br /> lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868<br /> down_read+0x46/0x2e0 kernel/locking/rwsem.c:1537<br /> f2fs_down_read fs/f2fs/f2fs.h:2278 [inline]<br /> f2fs_lock_op fs/f2fs/f2fs.h:2357 [inline]<br /> f2fs_do_truncate_blocks+0x21c/0x10c0 fs/f2fs/file.c:791<br /> f2fs_truncate_blocks+0x10a/0x300 fs/f2fs/file.c:867<br /> f2fs_truncate+0x489/0x7c0 fs/f2fs/file.c:925<br /> f2fs_evict_inode+0x9f2/0x1b60 fs/f2fs/inode.c:897<br /> evict+0x504/0x9c0 fs/inode.c:810<br /> f2fs_evict_inode+0x1dc/0x1b60 fs/f2fs/inode.c:853<br /> evict+0x504/0x9c0 fs/inode.c:810<br /> dispose_list fs/inode.c:852 [inline]<br /> prune_icache_sb+0x21b/0x2c0 fs/inode.c:1000<br /> super_cache_scan+0x39b/0x4b0 fs/super.c:224<br /> do_shrink_slab+0x6ef/0x1110 mm/shrinker.c:437<br /> shrink_slab_memcg mm/shrinker.c:550 [inline]<br /> shrink_slab+0x7ef/0x10d0 mm/shrinker.c:628<br /> shrink_one+0x28a/0x7c0 mm/vmscan.c:4955<br /> shrink_many mm/vmscan.c:5016 [inline]<br /> lru_gen_shrink_node mm/vmscan.c:5094 [inline]<br /> shrink_node+0x315d/0x3780 mm/vmscan.c:6081<br /> kswapd_shrink_node mm/vmscan.c:6941 [inline]<br /> balance_pgdat mm/vmscan.c:7124 [inline]<br /> kswapd+0x147c/0x2800 mm/vmscan.c:7389<br /> kthread+0x70e/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> <br /> The root cause is deadlock among four locks as below:<br /> <br /> kswapd<br /> - fs_reclaim --- Lock A<br /> - shrink_one<br /> - evict<br /> - f2fs_evict_inode<br /> - sb_start_intwrite --- Lock B<br /> <br /> - iput<br /> - evict<br /> - f2fs_evict_inode<br /> - sb_start_intwrite --- Lock B<br /> - f2fs_truncate<br /> - f2fs_truncate_blocks<br /> - f2fs_do_truncate_blocks<br /> - f2fs_lock_op --- Lock C<br /> <br /> ioctl<br /> - f2fs_ioc_commit_atomic_write<br /> - f2fs_lock_op --- Lock C<br /> - __f2fs_commit_atomic_write<br /> - __replace_atomic_write_block<br /> - f2fs_get_dnode_of_data<br /> - __get_node_folio<br /> - f2fs_check_nid_range<br /> - f2fs_handle_error<br /> - f2fs_record_errors<br /> - f2fs_down_write --- Lock D<br /> <br /> open<br /> - do_open<br /> - do_truncate<br /> - security_inode_need_killpriv<br /> - f2fs_getxattr<br /> - lookup_all_xattrs<br /> - f2fs_handle_error<br /> - f2fs_record_errors<br /> - f2fs_down_write --- Lock D<br /> - f2fs_commit_super<br /> - read_mapping_folio<br /> - filemap_alloc_folio_noprof<br /> - prepare_alloc_pages<br /> - fs_reclaim_acquire --- Lock A<br /> <br /> In order to a<br /> ---truncated---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: ets: Siempre eliminar la clase de la lista activa antes de eliminar en ets_qdisc_change<br /> <br /> zdi-disclosures@trendmicro.com dice:<br /> <br /> La vulnerabilidad es una condición de carrera entre &amp;#39;ets_qdisc_dequeue&amp;#39; y<br /> &amp;#39;ets_qdisc_change&amp;#39;. Conduce a UAF en el objeto &amp;#39;struct Qdisc&amp;#39;.<br /> El atacante requiere la capacidad de crear un nuevo usuario y un espacio de nombres de red<br /> para activar el error.<br /> Ver mi comentario adicional al final del análisis.<br /> <br /> Análisis:<br /> <br /> static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt,<br /> struct netlink_ext_ack *extack)<br /> {<br /> ...<br /> <br /> // (1) este bloqueo está evitando que el manejador .change (&amp;#39;ets_qdisc_change&amp;#39;)<br /> //compita con el manejador .dequeue (&amp;#39;ets_qdisc_dequeue&amp;#39;)<br /> sch_tree_lock(sch);<br /> <br /> for (i = nbands; i &amp;lt; oldbands; i++) {<br /> if (i &amp;gt;= q-&amp;gt;nstrict &amp;amp;&amp;amp; q-&amp;gt;classes[i].qdisc-&amp;gt;q.qlen)<br /> list_del_init(&amp;amp;q-&amp;gt;classes[i].alist);<br /> qdisc_purge_queue(q-&amp;gt;classes[i].qdisc);<br /> }<br /> <br /> WRITE_ONCE(q-&amp;gt;nbands, nbands);<br /> for (i = nstrict; i &amp;lt; q-&amp;gt;nstrict; i++) {<br /> if (q-&amp;gt;classes[i].qdisc-&amp;gt;q.qlen) {<br /> // (2) la clase se añade a q-&amp;gt;active<br /> list_add_tail(&amp;amp;q-&amp;gt;classes[i].alist, &amp;amp;q-&amp;gt;active);<br /> q-&amp;gt;classes[i].deficit = quanta[i];<br /> }<br /> }<br /> WRITE_ONCE(q-&amp;gt;nstrict, nstrict);<br /> memcpy(q-&amp;gt;prio2band, priomap, sizeof(priomap));<br /> <br /> for (i = 0; i &amp;lt; q-&amp;gt;nbands; i++)<br /> WRITE_ONCE(q-&amp;gt;classes[i].quantum, quanta[i]);<br /> <br /> for (i = oldbands; i &amp;lt; q-&amp;gt;nbands; i++) {<br /> q-&amp;gt;classes[i].qdisc = queues[i];<br /> if (q-&amp;gt;classes[i].qdisc != &amp;amp;noop_qdisc)<br /> qdisc_hash_add(q-&amp;gt;classes[i].qdisc, true);<br /> }<br /> <br /> // (3) el qdisc se desbloquea, ahora dequeue puede ser llamado en paralelo<br /> // al resto del manejador .change<br /> sch_tree_unlock(sch);<br /> <br /> ets_offload_change(sch);<br /> for (i = q-&amp;gt;nbands; i &amp;lt; oldbands; i++) {<br /> // (4) estamos reduciendo el contador de referencias para el qdisc de nuestra clase y<br /> // liberándolo<br /> qdisc_put(q-&amp;gt;classes[i].qdisc);<br /> // (5) Si llamamos a .dequeue entre (4) y (5), tendremos<br /> // un UAF fuerte y podremos controlar RIP<br /> q-&amp;gt;classes[i].qdisc = NULL;<br /> WRITE_ONCE(q-&amp;gt;classes[i].quantum, 0);<br /> q-&amp;gt;classes[i].deficit = 0;<br /> gnet_stats_basic_sync_init(&amp;amp;q-&amp;gt;classes[i].bstats);<br /> memset(&amp;amp;q-&amp;gt;classes[i].qstats, 0, sizeof(q-&amp;gt;classes[i].qstats));<br /> }<br /> return 0;<br /> }<br /> <br /> Comentario:<br /> Esto sucede porque algunas de las clases tienen sus qdiscs asignados a<br /> NULL, pero permanecen en la lista activa. Este commit soluciona este problema al siempre<br /> eliminar la clase de la lista activa antes de eliminar y liberar su<br /> qdisc asociado.<br /> <br /> Pasos para Reproducir<br /> (versión recortada de lo que fue enviado por zdi-disclosures@trendmicro.com)<br /> <br /> ```<br /> DEV="${DEV:-lo}"<br /> ROOT_HANDLE="${ROOT_HANDLE:-1:}"<br /> BAND2_HANDLE="${BAND2_HANDLE:-20:}" # child under 1:2<br /> PING_BYTES="${PING_BYTES:-48}"<br /> PING_COUNT="${PING_COUNT:-200000}"<br /> PING_DST="${PING_DST:-127.0.0.1}"<br /> <br /> SLOW_TBF_RATE="${SLOW_TBF_RATE:-8bit}"<br /> SLOW_TBF_BURST="${SLOW_TBF_BURST:-100b}"<br /> SLOW_TBF_LAT="${SLOW_TBF_LAT:-1s}"<br /> <br /> cleanup() {<br /> tc qdisc del dev "$DEV" root 2&amp;gt;/dev/null<br /> }<br /> trap cleanup EXIT<br /> <br /> ip link set "$DEV" up<br /> <br /> tc qdisc del dev "$DEV" root 2&amp;gt;/dev/null || true<br /> <br /> tc qdisc add dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2<br /> <br /> tc qdisc add dev "$DEV" parent 1:2 handle "$BAND2_HANDLE" \<br /> tbf rate "$SLOW_TBF_RATE" burst "$SLOW_TBF_BURST" latency "$SLOW_TBF_LAT"<br /> <br /> tc filter add dev "$DEV" parent 1: protocol all prio 1 u32 match u32 0 0 flowid 1:2<br /> tc -s qdisc ls dev $DEV<br /> <br /> ping -I "$DEV" -f -c "$PING_COUNT" -s "$PING_BYTES" -W 0.001 "$PING_DST" \<br /> &amp;gt;/dev/null 2&amp;gt;&amp;amp;1 &amp;amp;<br /> tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 0<br /> tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2<br /> tc -s qdisc ls dev $DEV<br /> tc qdisc del dev "$DEV" parent <br /> ---truncated---<br /> ```

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ublk: soluciona un interbloqueo al leer la tabla de particiones<br /> <br /> Cuando un proceso (como udev) abre el dispositivo de bloques ublk (por ejemplo, para leer la tabla de particiones a través de bdev_open()), puede ocurrir un interbloqueo[1]:<br /> <br /> 1. bdev_open() adquiere disk-&amp;gt;open_mutex<br /> 2. El proceso emite E/S de lectura al backend de ublk para leer la tabla de particiones<br /> 3. En __ublk_complete_rq(), blk_update_request() o blk_mq_end_request() ejecuta las retrollamadas bio-&amp;gt;bi_end_io()<br /> 4. Si esto activa fput() en el descriptor de archivo del dispositivo de bloques ublk, el trabajo puede ser aplazado al trabajo de tarea de la tarea actual (ver la implementación de fput())<br /> 5. Esto finalmente llama a blkdev_release() desde el mismo contexto<br /> 6. blkdev_release() intenta adquirir disk-&amp;gt;open_mutex de nuevo<br /> 7. Interbloqueo: misma tarea esperando por un mutex que ya posee<br /> <br /> La solución es ejecutar blk_update_request() y blk_mq_end_request() con las mitades inferiores deshabilitadas. Esto fuerza a blkdev_release() a ejecutarse en el contexto de la cola de trabajo del kernel en lugar del contexto de trabajo de la tarea actual, y permite al servidor ublk avanzar, y evita el interbloqueo.<br /> <br /> [axboe: reescribir comentario en ublk]

Proyecto Portal de Noticias phpgurukul V4.1 tiene una vulnerabilidad de eliminación arbitraria de archivos en remove_file.php. El parámetro file puede causar que cualquier archivo sea eliminado.

Proyecto de Portal de Noticias phpgurukul V4.1 es vulnerable a inyección SQL en check_availablity.php.

phpgurukul News Portal Project V4.1 tiene Vulnerabilidad de Carga de Archivos a través de upload.php, lo que permite la carga de archivos de cualquier formato al servidor sin autenticación de identidad.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: Revertir "scsi: qla2xxx: Realizar la finalización de comandos sin bloqueo en la ruta de aborto"<br /> <br /> Esto revierte el commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.<br /> <br /> El commit que se revierte añadió código a __qla2x00_abort_all_cmds() para llamar a sp-&amp;gt;done() sin mantener un spinlock. Pero a diferencia del código anterior debajo de él, este nuevo código no verificó sp-&amp;gt;cmd_type y simplemente asumió TYPE_SRB, lo que resulta en un salto a un puntero inválido en modo objetivo con TYPE_TGT_CMD:<br /> <br /> qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success<br /> 0000000009f7a79b<br /> qla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h<br /> mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.<br /> qla2xxx [0000:65:00.0]-d01e:8: -&amp;gt; fwdump no buffer<br /> qla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event<br /> 0x8002 occurred<br /> qla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery -<br /> ha=0000000058183fda.<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PF: supervisor instruction fetch in kernel mode<br /> PF: error_code(0x0010) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0010 [#1] SMP<br /> CPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1<br /> Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023<br /> RIP: 0010:0x0<br /> Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206<br /> RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000<br /> RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0<br /> RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045<br /> R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40<br /> R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400<br /> FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __die+0x4d/0x8b<br /> ? page_fault_oops+0x91/0x180<br /> ? trace_buffer_unlock_commit_regs+0x38/0x1a0<br /> ? exc_page_fault+0x391/0x5e0<br /> ? asm_exc_page_fault+0x22/0x30<br /> __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst]<br /> qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst]<br /> qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst]<br /> qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst]<br /> qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst]<br /> kthread+0xa8/0xd0<br /> <br /> <br /> Luego el commit 4475afa2646d (&amp;#39;scsi: qla2xxx: Completar comando temprano dentro del bloqueo&amp;#39;) añadió el spinlock de nuevo, porque no tener el bloqueo causó una condición de carrera y un fallo. Pero qla2x00_abort_srb() en el switch de abajo ya verifica qla2x00_chip_is_down() y lo maneja de la misma manera, por lo que el código encima del switch es ahora redundante y sigue siendo defectuoso en modo objetivo. Elimínelo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: dvb-usb: dtv5100: corrección de acceso fuera de límites en dtv5100_i2c_msg()<br /> <br /> El valor de rlen es un valor controlado por el usuario, pero dtv5100_i2c_msg() no verifica el tamaño del valor de rlen. Por lo tanto, si se establece en un valor mayor que sizeof(st-&amp;gt;data), ocurre una vulnerabilidad de acceso fuera de límites para st-&amp;gt;data.<br /> <br /> Por lo tanto, necesitamos añadir una verificación de rango adecuada para prevenir esta vulnerabilidad.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ext4: xattr: corregir desreferencia de puntero nulo en ext4_raw_inode()<br /> <br /> Si ext4_get_inode_loc() falla (p. ej., si devuelve -EFSCORRUPTED), iloc.bh permanecerá establecido en NULL. Dado que ext4_xattr_inode_dec_ref_all() carece de comprobación de errores, esto conducirá a una desreferencia de puntero nulo en ext4_raw_inode(), llamada justo después de ext4_get_inode_loc().<br /> <br /> Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.