Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: sysctl: udp_port: avoid using current-&gt;nsproxy<br /> <br /> As mentioned in a previous commit of this series, using the &amp;#39;net&amp;#39;<br /> structure via &amp;#39;current&amp;#39; is not recommended for different reasons:<br /> <br /> - Inconsistency: getting info from the reader&amp;#39;s/writer&amp;#39;s netns vs only<br /> from the opener&amp;#39;s netns.<br /> <br /> - current-&gt;nsproxy can be NULL in some cases, resulting in an &amp;#39;Oops&amp;#39;<br /> (null-ptr-deref), e.g. when the current task is exiting, as spotted by<br /> syzbot [1] using acct(2).<br /> <br /> The &amp;#39;net&amp;#39; structure can be obtained from the table-&gt;data using<br /> container_of().<br /> <br /> Note that table-&gt;data could also be used directly, but that would<br /> increase the size of this fix, while &amp;#39;sctp.ctl_sock&amp;#39; still needs to be<br /> retrieved from &amp;#39;net&amp;#39; structure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: sysctl: rto_min/max: avoid using current-&gt;nsproxy<br /> <br /> As mentioned in a previous commit of this series, using the &amp;#39;net&amp;#39;<br /> structure via &amp;#39;current&amp;#39; is not recommended for different reasons:<br /> <br /> - Inconsistency: getting info from the reader&amp;#39;s/writer&amp;#39;s netns vs only<br /> from the opener&amp;#39;s netns.<br /> <br /> - current-&gt;nsproxy can be NULL in some cases, resulting in an &amp;#39;Oops&amp;#39;<br /> (null-ptr-deref), e.g. when the current task is exiting, as spotted by<br /> syzbot [1] using acct(2).<br /> <br /> The &amp;#39;net&amp;#39; structure can be obtained from the table-&gt;data using<br /> container_of().<br /> <br /> Note that table-&gt;data could also be used directly, as this is the only<br /> member needed from the &amp;#39;net&amp;#39; structure, but that would increase the size<br /> of this fix, to use &amp;#39;*data&amp;#39; everywhere &amp;#39;net-&gt;sctp.rto_min/max&amp;#39; is used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: sysctl: auth_enable: avoid using current-&gt;nsproxy<br /> <br /> As mentioned in a previous commit of this series, using the &amp;#39;net&amp;#39;<br /> structure via &amp;#39;current&amp;#39; is not recommended for different reasons:<br /> <br /> - Inconsistency: getting info from the reader&amp;#39;s/writer&amp;#39;s netns vs only<br /> from the opener&amp;#39;s netns.<br /> <br /> - current-&gt;nsproxy can be NULL in some cases, resulting in an &amp;#39;Oops&amp;#39;<br /> (null-ptr-deref), e.g. when the current task is exiting, as spotted by<br /> syzbot [1] using acct(2).<br /> <br /> The &amp;#39;net&amp;#39; structure can be obtained from the table-&gt;data using<br /> container_of().<br /> <br /> Note that table-&gt;data could also be used directly, but that would<br /> increase the size of this fix, while &amp;#39;sctp.ctl_sock&amp;#39; still needs to be<br /> retrieved from &amp;#39;net&amp;#39; structure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: sysctl: cookie_hmac_alg: avoid using current-&gt;nsproxy<br /> <br /> As mentioned in a previous commit of this series, using the &amp;#39;net&amp;#39;<br /> structure via &amp;#39;current&amp;#39; is not recommended for different reasons:<br /> <br /> - Inconsistency: getting info from the reader&amp;#39;s/writer&amp;#39;s netns vs only<br /> from the opener&amp;#39;s netns.<br /> <br /> - current-&gt;nsproxy can be NULL in some cases, resulting in an &amp;#39;Oops&amp;#39;<br /> (null-ptr-deref), e.g. when the current task is exiting, as spotted by<br /> syzbot [1] using acct(2).<br /> <br /> The &amp;#39;net&amp;#39; structure can be obtained from the table-&gt;data using<br /> container_of().<br /> <br /> Note that table-&gt;data could also be used directly, as this is the only<br /> member needed from the &amp;#39;net&amp;#39; structure, but that would increase the size<br /> of this fix, to use &amp;#39;*data&amp;#39; everywhere &amp;#39;net-&gt;sctp.sctp_hmac_alg&amp;#39; is<br /> used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Ensure shadow stack is active before "getting" registers<br /> <br /> The x86 shadow stack support has its own set of registers. Those registers<br /> are XSAVE-managed, but they are "supervisor state components" which means<br /> that userspace can not touch them with XSAVE/XRSTOR. It also means that<br /> they are not accessible from the existing ptrace ABI for XSAVE state.<br /> Thus, there is a new ptrace get/set interface for it.<br /> <br /> The regset code that ptrace uses provides an -&gt;active() handler in<br /> addition to the get/set ones. For shadow stack this -&gt;active() handler<br /> verifies that shadow stack is enabled via the ARCH_SHSTK_SHSTK bit in the<br /> thread struct. The -&gt;active() handler is checked from some call sites of<br /> the regset get/set handlers, but not the ptrace ones. This was not<br /> understood when shadow stack support was put in place.<br /> <br /> As a result, both the set/get handlers can be called with<br /> XFEATURE_CET_USER in its init state, which would cause get_xsave_addr() to<br /> return NULL and trigger a WARN_ON(). The ssp_set() handler luckily has an<br /> ssp_active() check to avoid surprising the kernel with shadow stack<br /> behavior when the kernel is not ready for it (ARCH_SHSTK_SHSTK==0). That<br /> check just happened to avoid the warning.<br /> <br /> But the -&gt;get() side wasn&amp;#39;t so lucky. It can be called with shadow stacks<br /> disabled, triggering the warning in practice, as reported by Christina<br /> Schimpe:<br /> <br /> WARNING: CPU: 5 PID: 1773 at arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0<br /> [...]<br /> Call Trace:<br /> <br /> ? show_regs+0x6e/0x80<br /> ? ssp_get+0x89/0xa0<br /> ? __warn+0x91/0x150<br /> ? ssp_get+0x89/0xa0<br /> ? report_bug+0x19d/0x1b0<br /> ? handle_bug+0x46/0x80<br /> ? exc_invalid_op+0x1d/0x80<br /> ? asm_exc_invalid_op+0x1f/0x30<br /> ? __pfx_ssp_get+0x10/0x10<br /> ? ssp_get+0x89/0xa0<br /> ? ssp_get+0x52/0xa0<br /> __regset_get+0xad/0xf0<br /> copy_regset_to_user+0x52/0xc0<br /> ptrace_regset+0x119/0x140<br /> ptrace_request+0x13c/0x850<br /> ? wait_task_inactive+0x142/0x1d0<br /> ? do_syscall_64+0x6d/0x90<br /> arch_ptrace+0x102/0x300<br /> [...]<br /> <br /> Ensure that shadow stacks are active in a thread before looking them up<br /> in the XSAVE buffer. Since ARCH_SHSTK_SHSTK and user_ssp[SHSTK_EN] are<br /> set at the same time, the active check ensures that there will be<br /> something to find in the XSAVE buffer.<br /> <br /> [ dhansen: changelog/subject tweaks ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup/cpuset: remove kernfs active break<br /> <br /> A warning was found:<br /> <br /> WARNING: CPU: 10 PID: 3486953 at fs/kernfs/file.c:828<br /> CPU: 10 PID: 3486953 Comm: rmdir Kdump: loaded Tainted: G<br /> RIP: 0010:kernfs_should_drain_open_files+0x1a1/0x1b0<br /> RSP: 0018:ffff8881107ef9e0 EFLAGS: 00010202<br /> RAX: 0000000080000002 RBX: ffff888154738c00 RCX: dffffc0000000000<br /> RDX: 0000000000000007 RSI: 0000000000000004 RDI: ffff888154738c04<br /> RBP: ffff888154738c04 R08: ffffffffaf27fa15 R09: ffffed102a8e7180<br /> R10: ffff888154738c07 R11: 0000000000000000 R12: ffff888154738c08<br /> R13: ffff888750f8c000 R14: ffff888750f8c0e8 R15: ffff888154738ca0<br /> FS: 00007f84cd0be740(0000) GS:ffff8887ddc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000555f9fbe00c8 CR3: 0000000153eec001 CR4: 0000000000370ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> kernfs_drain+0x15e/0x2f0<br /> __kernfs_remove+0x165/0x300<br /> kernfs_remove_by_name_ns+0x7b/0xc0<br /> cgroup_rm_file+0x154/0x1c0<br /> cgroup_addrm_files+0x1c2/0x1f0<br /> css_clear_dir+0x77/0x110<br /> kill_css+0x4c/0x1b0<br /> cgroup_destroy_locked+0x194/0x380<br /> cgroup_rmdir+0x2a/0x140<br /> <br /> It can be explained by:<br /> rmdir echo 1 &gt; cpuset.cpus<br /> kernfs_fop_write_iter // active=0<br /> cgroup_rm_file<br /> kernfs_remove_by_name_ns kernfs_get_active // active=1<br /> __kernfs_remove // active=0x80000002<br /> kernfs_drain cpuset_write_resmask<br /> wait_event<br /> //waiting (active == 0x80000001)<br /> kernfs_break_active_protection<br /> // active = 0x80000001<br /> // continue<br /> kernfs_unbreak_active_protection<br /> // active = 0x80000002<br /> ...<br /> kernfs_should_drain_open_files<br /> // warning occurs<br /> kernfs_put_active<br /> <br /> This warning is caused by &amp;#39;kernfs_break_active_protection&amp;#39; when it is<br /> writing to cpuset.cpus, and the cgroup is removed concurrently.<br /> <br /> The commit 3a5a6d0c2b03 ("cpuset: don&amp;#39;t nest cgroup_mutex inside<br /> get_online_cpus()") made cpuset_hotplug_workfn asynchronous, This change<br /> involves calling flush_work(), which can create a multiple processes<br /> circular locking dependency that involve cgroup_mutex, potentially leading<br /> to a deadlock. To avoid deadlock. the commit 76bb5ab8f6e3 ("cpuset: break<br /> kernfs active protection in cpuset_write_resmask()") added<br /> &amp;#39;kernfs_break_active_protection&amp;#39; in the cpuset_write_resmask. This could<br /> lead to this warning.<br /> <br /> After the commit 2125c0034c5d ("cgroup/cpuset: Make cpuset hotplug<br /> processing synchronous"), the cpuset_write_resmask no longer needs to<br /> wait the hotplug to finish, which means that concurrent hotplug and cpuset<br /> operations are no longer possible. Therefore, the deadlock doesn&amp;#39;t exist<br /> anymore and it does not have to &amp;#39;break active protection&amp;#39; now. To fix this<br /> warning, just remove kernfs_break_active_protection operation in the<br /> &amp;#39;cpuset_write_resmask&amp;#39;.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block, bfq: fix waker_bfqq UAF after bfq_split_bfqq()<br /> <br /> Our syzkaller report a following UAF for v6.6:<br /> <br /> BUG: KASAN: slab-use-after-free in bfq_init_rq+0x175d/0x17a0 block/bfq-iosched.c:6958<br /> Read of size 8 at addr ffff8881b57147d8 by task fsstress/232726<br /> <br /> CPU: 2 PID: 232726 Comm: fsstress Not tainted 6.6.0-g3629d1885222 #39<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106<br /> print_address_description.constprop.0+0x66/0x300 mm/kasan/report.c:364<br /> print_report+0x3e/0x70 mm/kasan/report.c:475<br /> kasan_report+0xb8/0xf0 mm/kasan/report.c:588<br /> hlist_add_head include/linux/list.h:1023 [inline]<br /> bfq_init_rq+0x175d/0x17a0 block/bfq-iosched.c:6958<br /> bfq_insert_request.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271<br /> bfq_insert_requests+0x27f/0x390 block/bfq-iosched.c:6323<br /> blk_mq_insert_request+0x290/0x8f0 block/blk-mq.c:2660<br /> blk_mq_submit_bio+0x1021/0x15e0 block/blk-mq.c:3143<br /> __submit_bio+0xa0/0x6b0 block/blk-core.c:639<br /> __submit_bio_noacct_mq block/blk-core.c:718 [inline]<br /> submit_bio_noacct_nocheck+0x5b7/0x810 block/blk-core.c:747<br /> submit_bio_noacct+0xca0/0x1990 block/blk-core.c:847<br /> __ext4_read_bh fs/ext4/super.c:205 [inline]<br /> ext4_read_bh+0x15e/0x2e0 fs/ext4/super.c:230<br /> __read_extent_tree_block+0x304/0x6f0 fs/ext4/extents.c:567<br /> ext4_find_extent+0x479/0xd20 fs/ext4/extents.c:947<br /> ext4_ext_map_blocks+0x1a3/0x2680 fs/ext4/extents.c:4182<br /> ext4_map_blocks+0x929/0x15a0 fs/ext4/inode.c:660<br /> ext4_iomap_begin_report+0x298/0x480 fs/ext4/inode.c:3569<br /> iomap_iter+0x3dd/0x1010 fs/iomap/iter.c:91<br /> iomap_fiemap+0x1f4/0x360 fs/iomap/fiemap.c:80<br /> ext4_fiemap+0x181/0x210 fs/ext4/extents.c:5051<br /> ioctl_fiemap.isra.0+0x1b4/0x290 fs/ioctl.c:220<br /> do_vfs_ioctl+0x31c/0x11a0 fs/ioctl.c:811<br /> __do_sys_ioctl fs/ioctl.c:869 [inline]<br /> __se_sys_ioctl+0xae/0x190 fs/ioctl.c:857<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> <br /> Allocated by task 232719:<br /> kasan_save_stack+0x22/0x50 mm/kasan/common.c:45<br /> kasan_set_track+0x25/0x30 mm/kasan/common.c:52<br /> __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328<br /> kasan_slab_alloc include/linux/kasan.h:188 [inline]<br /> slab_post_alloc_hook mm/slab.h:768 [inline]<br /> slab_alloc_node mm/slub.c:3492 [inline]<br /> kmem_cache_alloc_node+0x1b8/0x6f0 mm/slub.c:3537<br /> bfq_get_queue+0x215/0x1f00 block/bfq-iosched.c:5869<br /> bfq_get_bfqq_handle_split+0x167/0x5f0 block/bfq-iosched.c:6776<br /> bfq_init_rq+0x13a4/0x17a0 block/bfq-iosched.c:6938<br /> bfq_insert_request.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271<br /> bfq_insert_requests+0x27f/0x390 block/bfq-iosched.c:6323<br /> blk_mq_insert_request+0x290/0x8f0 block/blk-mq.c:2660<br /> blk_mq_submit_bio+0x1021/0x15e0 block/blk-mq.c:3143<br /> __submit_bio+0xa0/0x6b0 block/blk-core.c:639<br /> __submit_bio_noacct_mq block/blk-core.c:718 [inline]<br /> submit_bio_noacct_nocheck+0x5b7/0x810 block/blk-core.c:747<br /> submit_bio_noacct+0xca0/0x1990 block/blk-core.c:847<br /> __ext4_read_bh fs/ext4/super.c:205 [inline]<br /> ext4_read_bh_nowait+0x15a/0x240 fs/ext4/super.c:217<br /> ext4_read_bh_lock+0xac/0xd0 fs/ext4/super.c:242<br /> ext4_bread_batch+0x268/0x500 fs/ext4/inode.c:958<br /> __ext4_find_entry+0x448/0x10f0 fs/ext4/namei.c:1671<br /> ext4_lookup_entry fs/ext4/namei.c:1774 [inline]<br /> ext4_lookup.part.0+0x359/0x6f0 fs/ext4/namei.c:1842<br /> ext4_lookup+0x72/0x90 fs/ext4/namei.c:1839<br /> __lookup_slow+0x257/0x480 fs/namei.c:1696<br /> lookup_slow fs/namei.c:1713 [inline]<br /> walk_component+0x454/0x5c0 fs/namei.c:2004<br /> link_path_walk.part.0+0x773/0xda0 fs/namei.c:2331<br /> link_path_walk fs/namei.c:3826 [inline]<br /> path_openat+0x1b9/0x520 fs/namei.c:3826<br /> do_filp_open+0x1b7/0x400 fs/namei.c:3857<br /> do_sys_openat2+0x5dc/0x6e0 fs/open.c:1428<br /> do_sys_open fs/open.c:1443 [inline]<br /> __do_sys_openat fs/open.c:1459 [inline]<br /> __se_sys_openat fs/open.c:1454 [inline]<br /> __x64_sys_openat+0x148/0x200 fs/open.c:1454<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_6<br /> ---truncated---

A vulnerability classified as problematic was found in Epic Games Launcher up to 17.2.1. This vulnerability affects unknown code in the library profapi.dll of the component Installer. The manipulation leads to untrusted search path. Attacking locally is a requirement. The complexity of an attack is rather high. The exploitation appears to be difficult.

A vulnerability classified as critical has been found in Tenda AC15 15.13.07.13. This affects the function formSetDevNetName of the file /goform/SetDevNetName. The manipulation of the argument mac leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.

A vulnerability was found in ZZCMS 2023. It has been rated as critical. Affected by this issue is some unknown functionality of the file /index.php. The manipulation of the argument id leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.

The Import any XML or CSV File to WordPress PRO plugin for WordPress is vulnerable to Stored Cross-Site Scripting via SVG File uploads in all versions up to, and including, 4.9.7 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Administrator-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses the SVG file.