Vulnerabilities

A vulnerability was found in itning Student Homework Management System up to 1.2.7. It has been declared as problematic. Affected by this vulnerability is an unknown functionality. The manipulation leads to cross-site request forgery. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. Multiple endpoints might be affected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().<br /> <br /> fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything<br /> when it fails.<br /> <br /> Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh")<br /> moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()<br /> but forgot to add cleanup for fib6_nh-&gt;nh_common.nhc_pcpu_rth_output in<br /> case it fails to allocate fib6_nh-&gt;rt6i_pcpu, resulting in memleak.<br /> <br /> Let&amp;#39;s call fib_nh_common_release() and clear nhc_pcpu_rth_output in the<br /> error path.<br /> <br /> Note that we can remove the fib6_nh_release() call in nh_create_ipv6()<br /> later in net-next.git.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix error code in chan_alloc_skb_cb()<br /> <br /> The chan_alloc_skb_cb() function is supposed to return error pointers on<br /> error. Returning NULL will lead to a NULL dereference.

The User Submitted Posts – Enable Users to Submit Posts from the Front End plugin for WordPress is vulnerable to Stored Cross-Site Scripting via admin settings in all versions up to, and including, 20240319 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: qcom: uefisecapp: fix efivars registration race<br /> <br /> Since the conversion to using the TZ allocator, the efivars service is<br /> registered before the memory pool has been allocated, something which<br /> can lead to a NULL-pointer dereference in case of a racing EFI variable<br /> access.<br /> <br /> Make sure that all resources have been set up before registering the<br /> efivars.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/huge_memory: drop beyond-EOF folios with the right number of refs<br /> <br /> When an after-split folio is large and needs to be dropped due to EOF,<br /> folio_put_refs(folio, folio_nr_pages(folio)) should be used to drop all<br /> page cache refs. Otherwise, the folio will not be freed, causing memory<br /> leak.<br /> <br /> This leak would happen on a filesystem with blocksize &gt; page_size and a<br /> truncate is performed, where the blocksize makes folios split to &gt;0 order<br /> ones, causing truncated folios not being freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/qaic: Fix integer overflow in qaic_validate_req()<br /> <br /> These are u64 variables that come from the user via<br /> qaic_attach_slice_bo_ioctl(). Use check_add_overflow() to ensure that<br /> the math doesn&amp;#39;t have an integer wrapping bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Call `invalidate_cache` only if implemented<br /> <br /> Many filesystems such as NFS and Ceph do not implement the<br /> `invalidate_cache` method. On those filesystems, if writing to the<br /> cache (`NETFS_WRITE_TO_CACHE`) fails for some reason, the kernel<br /> crashes like this:<br /> <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: Oops: 0010 [#1] SMP PTI<br /> CPU: 9 UID: 0 PID: 3380 Comm: kworker/u193:11 Not tainted 6.13.3-cm4all1-hp #437<br /> Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018<br /> Workqueue: events_unbound netfs_write_collection_worker<br /> RIP: 0010:0x0<br /> Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> RSP: 0018:ffff9b86e2ca7dc0 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 7fffffffffffffff<br /> RDX: 0000000000000001 RSI: ffff89259d576a18 RDI: ffff89259d576900<br /> RBP: ffff89259d5769b0 R08: ffff9b86e2ca7d28 R09: 0000000000000002<br /> R10: ffff89258ceaca80 R11: 0000000000000001 R12: 0000000000000020<br /> R13: ffff893d158b9338 R14: ffff89259d576900 R15: ffff89259d5769b0<br /> FS: 0000000000000000(0000) GS:ffff893c9fa40000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffffffffd6 CR3: 000000054442e003 CR4: 00000000001706f0<br /> Call Trace:<br /> <br /> ? __die+0x1f/0x60<br /> ? page_fault_oops+0x15c/0x460<br /> ? try_to_wake_up+0x2d2/0x530<br /> ? exc_page_fault+0x5e/0x100<br /> ? asm_exc_page_fault+0x22/0x30<br /> netfs_write_collection_worker+0xe9f/0x12b0<br /> ? xs_poll_check_readable+0x3f/0x80<br /> ? xs_stream_data_receive_workfn+0x8d/0x110<br /> process_one_work+0x134/0x2d0<br /> worker_thread+0x299/0x3a0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xba/0xe0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x30/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Modules linked in:<br /> CR2: 0000000000000000<br /> <br /> This patch adds the missing `NULL` check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: ucan: fix out of bound read in strscpy() source<br /> <br /> Commit 7fdaf8966aae ("can: ucan: use strscpy() to instead of strncpy()")<br /> unintentionally introduced a one byte out of bound read on strscpy()&amp;#39;s<br /> source argument (which is kind of ironic knowing that strscpy() is meant<br /> to be a more secure alternative :)).<br /> <br /> Let&amp;#39;s consider below buffers:<br /> <br /> dest[len + 1]; /* will be NUL terminated */<br /> src[len]; /* may not be NUL terminated */<br /> <br /> When doing:<br /> <br /> strncpy(dest, src, len);<br /> dest[len] = &amp;#39;\0&amp;#39;;<br /> <br /> strncpy() will read up to len bytes from src.<br /> <br /> On the other hand:<br /> <br /> strscpy(dest, src, len + 1);<br /> <br /> will read up to len + 1 bytes from src, that is to say, an out of bound<br /> read of one byte will occur on src if it is not NUL terminated. Note<br /> that the src[len] byte is never copied, but strscpy() still needs to<br /> read it to check whether a truncation occurred or not.<br /> <br /> This exact pattern happened in ucan.<br /> <br /> The root cause is that the source is not NUL terminated. Instead of<br /> doing a copy in a local buffer, directly NUL terminate it as soon as<br /> usb_control_msg() returns. With this, the local firmware_str[] variable<br /> can be removed.<br /> <br /> On top of this do a couple refactors:<br /> <br /> - ucan_ctl_payload-&gt;raw is only used for the firmware string, so<br /> rename it to ucan_ctl_payload-&gt;fw_str and change its type from u8 to<br /> char.<br /> <br /> - ucan_device_request_in() is only used to retrieve the firmware<br /> string, so rename it to ucan_get_fw_str() and refactor it to make it<br /> directly handle all the string termination logic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()<br /> <br /> On the off chance that command stream passed from userspace via<br /> ioctl() call to radeon_vce_cs_parse() is weirdly crafted and<br /> first command to execute is to encode (case 0x03000001), the function<br /> in question will attempt to call radeon_vce_cs_reloc() with size<br /> argument that has not been properly initialized. Specifically, &amp;#39;size&amp;#39;<br /> will point to &amp;#39;tmp&amp;#39; variable before the latter had a chance to be<br /> assigned any value.<br /> <br /> Play it safe and init &amp;#39;tmp&amp;#39; with 0, thus ensuring that<br /> radeon_vce_cs_reloc() will catch an early error in cases like these.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with static<br /> analysis tool SVACE.<br /> <br /> (cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: fix an integer overflow in xp_create_and_assign_umem()<br /> <br /> Since the i and pool-&gt;chunk_size variables are of type &amp;#39;u32&amp;#39;,<br /> their product can wrap around and then be cast to &amp;#39;u64&amp;#39;.<br /> This can lead to two different XDP buffers pointing to the same<br /> memory area.<br /> <br /> Found by InfoTeCS on behalf of Linux Verification Center<br /> (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> proc: fix UAF in proc_get_inode()<br /> <br /> Fix race between rmmod and /proc/XXX&amp;#39;s inode instantiation.<br /> <br /> The bug is that pde-&gt;proc_ops don&amp;#39;t belong to /proc, it belongs to a<br /> module, therefore dereferencing it after /proc entry has been registered<br /> is a bug unless use_pde/unuse_pde() pair has been used.<br /> <br /> use_pde/unuse_pde can be avoided (2 atomic ops!) because pde-&gt;proc_ops<br /> never changes so information necessary for inode instantiation can be<br /> saved _before_ proc_register() in PDE itself and used later, avoiding<br /> pde-&gt;proc_ops-&gt;... dereference.<br /> <br /> rmmod lookup<br /> sys_delete_module<br /> proc_lookup_de<br /> pde_get(de);<br /> proc_get_inode(dir-&gt;i_sb, de);<br /> mod-&gt;exit()<br /> proc_remove<br /> remove_proc_subtree<br /> proc_entry_rundown(de);<br /> free_module(mod);<br /> <br /> if (S_ISREG(inode-&gt;i_mode))<br /> if (de-&gt;proc_ops-&gt;proc_read_iter)<br /> --&gt; As module is already freed, will trigger UAF<br /> <br /> BUG: unable to handle page fault for address: fffffbfff80a702b<br /> PGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> RIP: 0010:proc_get_inode+0x302/0x6e0<br /> RSP: 0018:ffff88811c837998 EFLAGS: 00010a06<br /> RAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007<br /> RDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158<br /> RBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20<br /> R10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0<br /> R13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001<br /> FS: 00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> proc_lookup_de+0x11f/0x2e0<br /> __lookup_slow+0x188/0x350<br /> walk_component+0x2ab/0x4f0<br /> path_lookupat+0x120/0x660<br /> filename_lookup+0x1ce/0x560<br /> vfs_statx+0xac/0x150<br /> __do_sys_newstat+0x96/0x110<br /> do_syscall_64+0x5f/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> [adobriyan@gmail.com: don&amp;#39;t do 2 atomic ops on the common path]