Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fail bpf_timer_cancel when callback is being cancelled<br /> <br /> Given a schedule:<br /> <br /> timer1 cb timer2 cb<br /> <br /> bpf_timer_cancel(timer2); bpf_timer_cancel(timer1);<br /> <br /> Both bpf_timer_cancel calls would wait for the other callback to finish<br /> executing, introducing a lockup.<br /> <br /> Add an atomic_t count named &amp;#39;cancelling&amp;#39; in bpf_hrtimer. This keeps<br /> track of all in-flight cancellation requests for a given BPF timer.<br /> Whenever cancelling a BPF timer, we must check if we have outstanding<br /> cancellation requests, and if so, we must fail the operation with an<br /> error (-EDEADLK) since cancellation is synchronous and waits for the<br /> callback to finish executing. This implies that we can enter a deadlock<br /> situation involving two or more timer callbacks executing in parallel<br /> and attempting to cancel one another.<br /> <br /> Note that we avoid incrementing the cancelling counter for the target<br /> timer (the one being cancelled) if bpf_timer_cancel is not invoked from<br /> a callback, to avoid spurious errors. The whole point of detecting<br /> cur-&gt;cancelling and returning -EDEADLK is to not enter a busy wait loop<br /> (which may or may not lead to a lockup). This does not apply in case the<br /> caller is in a non-callback context, the other side can continue to<br /> cancel as it sees fit without running into errors.<br /> <br /> Background on prior attempts:<br /> <br /> Earlier versions of this patch used a bool &amp;#39;cancelling&amp;#39; bit and used the<br /> following pattern under timer-&gt;lock to publish cancellation status.<br /> <br /> lock(t-&gt;lock);<br /> t-&gt;cancelling = true;<br /> mb();<br /> if (cur-&gt;cancelling)<br /> return -EDEADLK;<br /> unlock(t-&gt;lock);<br /> hrtimer_cancel(t-&gt;timer);<br /> t-&gt;cancelling = false;<br /> <br /> The store outside the critical section could overwrite a parallel<br /> requests t-&gt;cancelling assignment to true, to ensure the parallely<br /> executing callback observes its cancellation status.<br /> <br /> It would be necessary to clear this cancelling bit once hrtimer_cancel<br /> is done, but lack of serialization introduced races. Another option was<br /> explored where bpf_timer_start would clear the bit when (re)starting the<br /> timer under timer-&gt;lock. This would ensure serialized access to the<br /> cancelling bit, but may allow it to be cleared before in-flight<br /> hrtimer_cancel has finished executing, such that lockups can occur<br /> again.<br /> <br /> Thus, we choose an atomic counter to keep track of all outstanding<br /> cancellation requests and use it to prevent lockups in case callbacks<br /> attempt to cancel each other while executing in parallel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/shmem: disable PMD-sized page cache if needed<br /> <br /> For shmem files, it&amp;#39;s possible that PMD-sized page cache can&amp;#39;t be<br /> supported by xarray. For example, 512MB page cache on ARM64 when the base<br /> page size is 64KB can&amp;#39;t be supported by xarray. It leads to errors as the<br /> following messages indicate when this sort of xarray entry is split.<br /> <br /> WARNING: CPU: 34 PID: 7578 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128<br /> Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 \<br /> nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject \<br /> nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \<br /> ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse xfs \<br /> libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_net \<br /> net_failover virtio_console virtio_blk failover dimlib virtio_mmio<br /> CPU: 34 PID: 7578 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9<br /> Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024<br /> pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : xas_split_alloc+0xf8/0x128<br /> lr : split_huge_page_to_list_to_order+0x1c4/0x720<br /> sp : ffff8000882af5f0<br /> x29: ffff8000882af5f0 x28: ffff8000882af650 x27: ffff8000882af768<br /> x26: 0000000000000cc0 x25: 000000000000000d x24: ffff00010625b858<br /> x23: ffff8000882af650 x22: ffffffdfc0900000 x21: 0000000000000000<br /> x20: 0000000000000000 x19: ffffffdfc0900000 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000018000000000 x15: 52f8004000000000<br /> x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020<br /> x11: 52f8000000000000 x10: 52f8e1c0ffff6000 x9 : ffffbeb9619a681c<br /> x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff00010b02ddb0<br /> x5 : ffffbeb96395e378 x4 : 0000000000000000 x3 : 0000000000000cc0<br /> x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000<br /> Call trace:<br /> xas_split_alloc+0xf8/0x128<br /> split_huge_page_to_list_to_order+0x1c4/0x720<br /> truncate_inode_partial_folio+0xdc/0x160<br /> shmem_undo_range+0x2bc/0x6a8<br /> shmem_fallocate+0x134/0x430<br /> vfs_fallocate+0x124/0x2e8<br /> ksys_fallocate+0x4c/0xa0<br /> __arm64_sys_fallocate+0x24/0x38<br /> invoke_syscall.constprop.0+0x7c/0xd8<br /> do_el0_svc+0xb4/0xd0<br /> el0_svc+0x44/0x1d8<br /> el0t_64_sync_handler+0x134/0x150<br /> el0t_64_sync+0x17c/0x180<br /> <br /> Fix it by disabling PMD-sized page cache when HPAGE_PMD_ORDER is larger<br /> than MAX_PAGECACHE_ORDER. As Matthew Wilcox pointed, the page cache in a<br /> shmem file isn&amp;#39;t represented by a multi-index entry and doesn&amp;#39;t have this<br /> limitation when the xarry entry is split until commit 6b24ca4a1a8d ("mm:<br /> Use multi-index entries in the page cache").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: fix race between delayed_work() and ceph_monc_stop()<br /> <br /> The way the delayed work is handled in ceph_monc_stop() is prone to<br /> races with mon_fault() and possibly also finish_hunting(). Both of<br /> these can requeue the delayed work which wouldn&amp;#39;t be canceled by any of<br /> the following code in case that happens after cancel_delayed_work_sync()<br /> runs -- __close_session() doesn&amp;#39;t mess with the delayed work in order<br /> to avoid interfering with the hunting interval logic. This part was<br /> missed in commit b5d91704f53e ("libceph: behave in mon_fault() if<br /> cur_mon auth and monc-&gt;monmap being<br /> particularly susceptible to quickly being reused.<br /> <br /> To fix this:<br /> <br /> - clear monc-&gt;cur_mon and monc-&gt;hunting as part of closing the session<br /> in ceph_monc_stop()<br /> - bail from delayed_work() if monc-&gt;cur_mon is cleared, similar to how<br /> it&amp;#39;s done in mon_fault() and finish_hunting() (based on monc-&gt;hunting)<br /> - call cancel_delayed_work_sync() after the session is closed

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()<br /> <br /> Userspace provided string &amp;#39;s&amp;#39; could trivially have the length zero. Left<br /> unchecked this will firstly result in an OOB read in the form<br /> `if (str[0 - 1] == &amp;#39;\n&amp;#39;) followed closely by an OOB write in the form<br /> `str[0 - 1] = &amp;#39;\0&amp;#39;`.<br /> <br /> There is already a validating check to catch strings that are too long.<br /> Let&amp;#39;s supply an additional check for invalid strings that are too short.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: cs_dsp: Validate payload length before processing block<br /> <br /> Move the payload length check in cs_dsp_load() and cs_dsp_coeff_load()<br /> to be done before the block is processed.<br /> <br /> The check that the length of a block payload does not exceed the number<br /> of remaining bytes in the firwmware file buffer was being done near the<br /> end of the loop iteration. However, some code before that check used the<br /> length field without validating it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: cs_dsp: Return error if block header overflows file<br /> <br /> Return an error from cs_dsp_power_up() if a block header is longer<br /> than the amount of data left in the file.<br /> <br /> The previous code in cs_dsp_load() and cs_dsp_load_coeff() would loop<br /> while there was enough data left in the file for a valid region. This<br /> protected against overrunning the end of the file data, but it didn&amp;#39;t<br /> abort the file processing with an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/bhi: Avoid warning in #DB handler due to BHI mitigation<br /> <br /> When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set<br /> then entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls the<br /> clear_bhb_loop() before the TF flag is cleared. This causes the #DB handler<br /> (exc_debug_kernel()) to issue a warning because single-step is used outside the<br /> entry_SYSENTER_compat() function.<br /> <br /> To address this issue, entry_SYSENTER_compat() should use CLEAR_BRANCH_HISTORY<br /> after making sure the TF flag is cleared.<br /> <br /> The problem can be reproduced with the following sequence:<br /> <br /> $ cat sysenter_step.c<br /> int main()<br /> { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); }<br /> <br /> $ gcc -o sysenter_step sysenter_step.c<br /> <br /> $ ./sysenter_step<br /> Segmentation fault (core dumped)<br /> <br /> The program is expected to crash, and the #DB handler will issue a warning.<br /> <br /> Kernel log:<br /> <br /> WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160<br /> ...<br /> RIP: 0010:exc_debug_kernel+0xd2/0x160<br /> ...<br /> Call Trace:<br /> <br /> ? show_regs+0x68/0x80<br /> ? __warn+0x8c/0x140<br /> ? exc_debug_kernel+0xd2/0x160<br /> ? report_bug+0x175/0x1a0<br /> ? handle_bug+0x44/0x90<br /> ? exc_invalid_op+0x1c/0x70<br /> ? asm_exc_invalid_op+0x1f/0x30<br /> ? exc_debug_kernel+0xd2/0x160<br /> exc_debug+0x43/0x50<br /> asm_exc_debug+0x1e/0x40<br /> RIP: 0010:clear_bhb_loop+0x0/0xb0<br /> ...<br /> <br /> <br /> ? entry_SYSENTER_compat_after_hwframe+0x6e/0x8d<br /> <br /> <br /> [ bp: Massage commit message. ]

An Incorrect Access Control vulnerability was found in /smsa/add_class.php and /smsa/add_class_submit.php in Kashipara Responsive School Management System v3.2.0, which allows remote unauthenticated attackers to add a new class entry.

An Incorrect Access Control vulnerability was found in /smsa/add_subject.php and /smsa/add_subject_submit.php in Kashipara Responsive School Management System v3.2.0, which allows remote unauthenticated attackers to add a new subject entry.

An Incorrect Access Control vulnerability was found in /smsa/view_subject.php in Kashipara Responsive School Management System v3.2.0, which allows remote unauthenticated attackers to view SUBJECT details.

An Incorrect Access Control vulnerability was found in /smsa/admin_teacher_register_approval.php and /smsa/admin_teacher_register_approval_submit.php in Kashipara Responsive School Management System v3.2.0, which allows remote unauthenticated attackers to view and approve Teacher registration.

An issue in the Ping feature of IT Solutions Enjay CRM OS v1.0 allows attackers to escape the restricted terminal environment and gain root-level privileges on the underlying system.