Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> functionfs: fix the open/removal races<br /> <br /> ffs_epfile_open() can race with removal, ending up with file-&gt;private_data<br /> pointing to freed object.<br /> <br /> There is a total count of opened files on functionfs (both ep0 and<br /> dynamic ones) and when it hits zero, dynamic files get removed.<br /> Unfortunately, that removal can happen while another thread is<br /> in ffs_epfile_open(), but has not incremented the count yet.<br /> In that case open will succeed, leaving us with UAF on any subsequent<br /> read() or write().<br /> <br /> The root cause is that ffs-&gt;opened is misused; atomic_dec_and_test() vs.<br /> atomic_add_return() is not a good idea, when object remains visible all<br /> along.<br /> <br /> To untangle that<br /> * serialize openers on ffs-&gt;mutex (both for ep0 and for dynamic files)<br /> * have dynamic ones use atomic_inc_not_zero() and fail if we had<br /> zero -&gt;opened; in that case the file we are opening is doomed.<br /> * have the inodes of dynamic files marked on removal (from the<br /> callback of simple_recursive_removal()) - clear -&gt;i_private there.<br /> * have open of dynamic ones verify they hadn&amp;#39;t been already removed,<br /> along with checking that state is FFS_ACTIVE.

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---

Tenda AX-3 v16.03.12.10_CN was discovered to contain a stack overflow in the wanSpeed2 parameter of the fromAdvSetMacMtuWan function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.

Tenda AX-3 v16.03.12.10_CN was discovered to contain a stack overflow in the wanMTU2 parameter of the fromAdvSetMacMtuWan function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.

Tenda AX-3 v16.03.12.10_CN was discovered to contain a stack overflow in the cloneType2 parameter of the fromAdvSetMacMtuWan function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.

Tenda AX-3 v16.03.12.10_CN was discovered to contain a stack overflow in the serviceName2 parameter of the fromAdvSetMacMtuWan function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.

Tenda AX-1806 v1.0.0.1 was discovered to contain a stack overflow in the security_5g parameter of the sub_4CA50 function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: using the num_tqps in the vf driver to apply for resources<br /> <br /> Currently, hdev-&gt;htqp is allocated using hdev-&gt;num_tqps, and kinfo-&gt;tqp<br /> is allocated using kinfo-&gt;num_tqps. However, kinfo-&gt;num_tqps is set to<br /> min(new_tqps, hdev-&gt;num_tqps); Therefore, kinfo-&gt;num_tqps may be smaller<br /> than hdev-&gt;num_tqps, which causes some hdev-&gt;htqp[i] to remain<br /> uninitialized in hclgevf_knic_setup().<br /> <br /> Thus, this patch allocates hdev-&gt;htqp and kinfo-&gt;tqp using hdev-&gt;num_tqps,<br /> ensuring that the lengths of hdev-&gt;htqp and kinfo-&gt;tqp are consistent<br /> and that all elements are properly initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: ets: Always remove class from active list before deleting in ets_qdisc_change<br /> <br /> zdi-disclosures@trendmicro.com says:<br /> <br /> The vulnerability is a race condition between `ets_qdisc_dequeue` and<br /> `ets_qdisc_change`. It leads to UAF on `struct Qdisc` object.<br /> Attacker requires the capability to create new user and network namespace<br /> in order to trigger the bug.<br /> See my additional commentary at the end of the analysis.<br /> <br /> Analysis:<br /> <br /> static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt,<br /> struct netlink_ext_ack *extack)<br /> {<br /> ...<br /> <br /> // (1) this lock is preventing .change handler (`ets_qdisc_change`)<br /> //to race with .dequeue handler (`ets_qdisc_dequeue`)<br /> sch_tree_lock(sch);<br /> <br /> for (i = nbands; i = q-&gt;nstrict &amp;&amp; q-&gt;classes[i].qdisc-&gt;q.qlen)<br /> list_del_init(&amp;q-&gt;classes[i].alist);<br /> qdisc_purge_queue(q-&gt;classes[i].qdisc);<br /> }<br /> <br /> WRITE_ONCE(q-&gt;nbands, nbands);<br /> for (i = nstrict; i nstrict; i++) {<br /> if (q-&gt;classes[i].qdisc-&gt;q.qlen) {<br /> // (2) the class is added to the q-&gt;active<br /> list_add_tail(&amp;q-&gt;classes[i].alist, &amp;q-&gt;active);<br /> q-&gt;classes[i].deficit = quanta[i];<br /> }<br /> }<br /> WRITE_ONCE(q-&gt;nstrict, nstrict);<br /> memcpy(q-&gt;prio2band, priomap, sizeof(priomap));<br /> <br /> for (i = 0; i nbands; i++)<br /> WRITE_ONCE(q-&gt;classes[i].quantum, quanta[i]);<br /> <br /> for (i = oldbands; i nbands; i++) {<br /> q-&gt;classes[i].qdisc = queues[i];<br /> if (q-&gt;classes[i].qdisc != &amp;noop_qdisc)<br /> qdisc_hash_add(q-&gt;classes[i].qdisc, true);<br /> }<br /> <br /> // (3) the qdisc is unlocked, now dequeue can be called in parallel<br /> // to the rest of .change handler<br /> sch_tree_unlock(sch);<br /> <br /> ets_offload_change(sch);<br /> for (i = q-&gt;nbands; i classes[i].qdisc);<br /> // (5) If we call .dequeue between (4) and (5), we will have<br /> // a strong UAF and we can control RIP<br /> q-&gt;classes[i].qdisc = NULL;<br /> WRITE_ONCE(q-&gt;classes[i].quantum, 0);<br /> q-&gt;classes[i].deficit = 0;<br /> gnet_stats_basic_sync_init(&amp;q-&gt;classes[i].bstats);<br /> memset(&amp;q-&gt;classes[i].qstats, 0, sizeof(q-&gt;classes[i].qstats));<br /> }<br /> return 0;<br /> }<br /> <br /> Comment:<br /> This happens because some of the classes have their qdiscs assigned to<br /> NULL, but remain in the active list. This commit fixes this issue by always<br /> removing the class from the active list before deleting and freeing its<br /> associated qdisc<br /> <br /> Reproducer Steps<br /> (trimmed version of what was sent by 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&gt;/dev/null<br /> }<br /> trap cleanup EXIT<br /> <br /> ip link set "$DEV" up<br /> <br /> tc qdisc del dev "$DEV" root 2&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 /> &gt;/dev/null 2&gt;&amp;1 &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---

Tenda AX-3 v16.03.12.10_CN was discovered to contain a stack overflow in the mac2 parameter of the fromAdvSetMacMtuWan function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: alps - fix use-after-free bugs caused by dev3_register_work<br /> <br /> The dev3_register_work delayed work item is initialized within<br /> alps_reconnect() and scheduled upon receipt of the first bare<br /> PS/2 packet from an external PS/2 device connected to the ALPS<br /> touchpad. During device detachment, the original implementation<br /> calls flush_workqueue() in psmouse_disconnect() to ensure<br /> completion of dev3_register_work. However, the flush_workqueue()<br /> in psmouse_disconnect() only blocks and waits for work items that<br /> were already queued to the workqueue prior to its invocation. Any<br /> work items submitted after flush_workqueue() is called are not<br /> included in the set of tasks that the flush operation awaits.<br /> This means that after flush_workqueue() has finished executing,<br /> the dev3_register_work could still be scheduled. Although the<br /> psmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),<br /> the scheduling of dev3_register_work remains unaffected.<br /> <br /> The race condition can occur as follows:<br /> <br /> CPU 0 (cleanup path) | CPU 1 (delayed work)<br /> psmouse_disconnect() |<br /> psmouse_set_state() |<br /> flush_workqueue() | alps_report_bare_ps2_packet()<br /> alps_disconnect() | psmouse_queue_work()<br /> kfree(priv); // FREE | alps_register_bare_ps2_mouse()<br /> | priv = container_of(work...); // USE<br /> | priv-&gt;dev3 // USE<br /> <br /> Add disable_delayed_work_sync() in alps_disconnect() to ensure<br /> that dev3_register_work is properly canceled and prevented from<br /> executing after the alps_data structure has been deallocated.<br /> <br /> This bug is identified by static analysis.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: fix deadlock when reading partition table<br /> <br /> When one process(such as udev) opens ublk block device (e.g., to read<br /> the partition table via bdev_open()), a deadlock[1] can occur:<br /> <br /> 1. bdev_open() grabs disk-&gt;open_mutex<br /> 2. The process issues read I/O to ublk backend to read partition table<br /> 3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request()<br /> runs bio-&gt;bi_end_io() callbacks<br /> 4. If this triggers fput() on file descriptor of ublk block device, the<br /> work may be deferred to current task&amp;#39;s task work (see fput() implementation)<br /> 5. This eventually calls blkdev_release() from the same context<br /> 6. blkdev_release() tries to grab disk-&gt;open_mutex again<br /> 7. Deadlock: same task waiting for a mutex it already holds<br /> <br /> The fix is to run blk_update_request() and blk_mq_end_request() with bottom<br /> halves disabled. This forces blkdev_release() to run in kernel work-queue<br /> context instead of current task work context, and allows ublk server to make<br /> forward progress, and avoids the deadlock.<br /> <br /> [axboe: rewrite comment in ublk]