Total
88191 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-42250 | 1 Linux | 1 Linux Kernel | 2024-08-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: cachefiles: add missing lock protection when polling Add missing lock protection in poll routine when iterating xarray, otherwise: Even with RCU read lock held, only the slot of the radix tree is ensured to be pinned there, while the data structure (e.g. struct cachefiles_req) stored in the slot has no such guarantee. The poll routine will iterate the radix tree and dereference cachefiles_req accordingly. Thus RCU read lock is not adequate in this case and spinlock is needed here. | |||||
| CVE-2024-6884 | 2024-08-08 | N/A | 5.4 MEDIUM | ||
| The Gutenberg Blocks with AI by Kadence WP WordPress plugin before 3.2.39 does not validate and escape some of its block options before outputting them back in a page/post where the block is embed, which could allow users with the contributor role and above to perform Stored Cross-Site Scripting attacks | |||||
| CVE-2024-41239 | 1 Lopalopa | 1 Responsive School Management System | 2024-08-08 | N/A | 4.8 MEDIUM |
| A Stored Cross Site Scripting (XSS) vulnerability was found in "/smsa/add_class_submit.php" in Responsive School Management System v3.2.0, which allows remote attackers to execute arbitrary code via "class_name" parameter field. | |||||
| CVE-2024-38888 | 2024-08-08 | N/A | 6.8 MEDIUM | ||
| An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a local attacker to perform a Password Brute Forcing attack due to improper restriction of excessive authentication attempts. | |||||
| CVE-2024-41242 | 1 Lopalopa | 1 Responsive School Management System | 2024-08-08 | N/A | 6.1 MEDIUM |
| A Reflected Cross Site Scripting (XSS) vulnerability was found in /smsa/student_login.php in Kashipara Responsive School Management System v3.2.0, which allows remote attackers to execute arbitrary code via "error" parameter. | |||||
| CVE-2024-41245 | 1 Lopalopa | 1 Responsive School Management System | 2024-08-08 | N/A | 5.3 MEDIUM |
| An Incorrect Access Control vulnerability was found in /smsa/view_teachers.php in Kashipara Responsive School Management System v3.2.0, which allows remote unauthenticated attackers to view TEACHER details. | |||||
| CVE-2024-41244 | 1 Lopalopa | 1 Responsive School Management System | 2024-08-08 | N/A | 5.3 MEDIUM |
| An Incorrect Access Control vulnerability was found in /smsa/view_class.php in Kashipara Responsive School Management System v3.2.0, which allows remote unauthenticated attackers to view CLASS details. | |||||
| CVE-2024-41247 | 1 Lopalopa | 1 Responsive School Management System | 2024-08-08 | N/A | 5.3 MEDIUM |
| 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. | |||||
| CVE-2024-41248 | 1 Lopalopa | 1 Responsive School Management System | 2024-08-08 | N/A | 5.3 MEDIUM |
| 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. | |||||
| CVE-2024-41249 | 1 Lopalopa | 1 Responsive School Management System | 2024-08-08 | N/A | 5.3 MEDIUM |
| 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. | |||||
| CVE-2024-41252 | 1 Lopalopa | 1 Responsive School Management System | 2024-08-08 | N/A | 6.5 MEDIUM |
| An Incorrect Access Control vulnerability was found in /smsa/admin_student_register_approval.php and /smsa/admin_student_register_approval_submit.php in Kashipara Responsive School Management System v3.2.0, which allows remote unauthenticated attackers to view and approve student registration. | |||||
| CVE-2024-41432 | 1 Likeshop | 1 Likeshop | 2024-08-08 | N/A | 5.3 MEDIUM |
| An IP Spoofing vulnerability has been discovered in Likeshop up to 2.5.7.20210811. This issue allows an attacker to replace their real IP address with any arbitrary IP address, specifically by adding a forged 'X-Forwarded' or 'Client-IP' header to requests. Exploiting IP spoofing, attackers can bypass account lockout mechanisms during attempts to log into admin accounts, spoof IP addresses in requests sent to the server, and impersonate IP addresses that have logged into user accounts, etc. | |||||
| CVE-2024-42232 | 1 Linux | 1 Linux Kernel | 2024-08-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: libceph: fix race between delayed_work() and ceph_monc_stop() The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused. To fix this: - clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop() - bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting) - call cancel_delayed_work_sync() after the session is closed | |||||
| CVE-2024-42234 | 1 Linux | 1 Linux Kernel | 2024-08-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: mm: fix crashes from deferred split racing folio migration Even on 6.10-rc6, I've been seeing elusive "Bad page state"s (often on flags when freeing, yet the flags shown are not bad: PG_locked had been set and cleared??), and VM_BUG_ON_PAGE(page_ref_count(page) == 0)s from deferred_split_scan()'s folio_put(), and a variety of other BUG and WARN symptoms implying double free by deferred split and large folio migration. 6.7 commit 9bcef5973e31 ("mm: memcg: fix split queue list crash when large folio migration") was right to fix the memcg-dependent locking broken in 85ce2c517ade ("memcontrol: only transfer the memcg data for migration"), but missed a subtlety of deferred_split_scan(): it moves folios to its own local list to work on them without split_queue_lock, during which time folio->_deferred_list is not empty, but even the "right" lock does nothing to secure the folio and the list it is on. Fortunately, deferred_split_scan() is careful to use folio_try_get(): so folio_migrate_mapping() can avoid the race by folio_undo_large_rmappable() while the old folio's reference count is temporarily frozen to 0 - adding such a freeze in the !mapping case too (originally, folio lock and unmapping and no swap cache left an anon folio unreachable, so no freezing was needed there: but the deferred split queue offers a way to reach it). | |||||
| CVE-2024-42235 | 1 Linux | 1 Linux Kernel | 2024-08-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: s390/mm: Add NULL pointer check to crst_table_free() base_crst_free() crst_table_free() used to work with NULL pointers before the conversion to ptdescs. Since crst_table_free() can be called with a NULL pointer (error handling in crst_table_upgrade() add an explicit check. Also add the same check to base_crst_free() for consistency reasons. In real life this should not happen, since order two GFP_KERNEL allocations will not fail, unless FAIL_PAGE_ALLOC is enabled and used. | |||||
| CVE-2024-42238 | 1 Linux | 1 Linux Kernel | 2024-08-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Return error if block header overflows file Return an error from cs_dsp_power_up() if a block header is longer than the amount of data left in the file. The previous code in cs_dsp_load() and cs_dsp_load_coeff() would loop while there was enough data left in the file for a valid region. This protected against overrunning the end of the file data, but it didn't abort the file processing with an error. | |||||
| CVE-2024-42236 | 1 Linux | 1 Linux Kernel | 2024-08-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: Prevent OOB read/write in usb_string_copy() Userspace provided string 's' could trivially have the length zero. Left unchecked this will firstly result in an OOB read in the form `if (str[0 - 1] == '\n') followed closely by an OOB write in the form `str[0 - 1] = '\0'`. There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short. | |||||
| CVE-2024-42237 | 1 Linux | 1 Linux Kernel | 2024-08-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Validate payload length before processing block Move the payload length check in cs_dsp_load() and cs_dsp_coeff_load() to be done before the block is processed. The check that the length of a block payload does not exceed the number of remaining bytes in the firwmware file buffer was being done near the end of the loop iteration. However, some code before that check used the length field without validating it. | |||||
| CVE-2024-42239 | 1 Linux | 1 Linux Kernel | 2024-08-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fail bpf_timer_cancel when callback is being cancelled Given a schedule: timer1 cb timer2 cb bpf_timer_cancel(timer2); bpf_timer_cancel(timer1); Both bpf_timer_cancel calls would wait for the other callback to finish executing, introducing a lockup. Add an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps track of all in-flight cancellation requests for a given BPF timer. Whenever cancelling a BPF timer, we must check if we have outstanding cancellation requests, and if so, we must fail the operation with an error (-EDEADLK) since cancellation is synchronous and waits for the callback to finish executing. This implies that we can enter a deadlock situation involving two or more timer callbacks executing in parallel and attempting to cancel one another. Note that we avoid incrementing the cancelling counter for the target timer (the one being cancelled) if bpf_timer_cancel is not invoked from a callback, to avoid spurious errors. The whole point of detecting cur->cancelling and returning -EDEADLK is to not enter a busy wait loop (which may or may not lead to a lockup). This does not apply in case the caller is in a non-callback context, the other side can continue to cancel as it sees fit without running into errors. Background on prior attempts: Earlier versions of this patch used a bool 'cancelling' bit and used the following pattern under timer->lock to publish cancellation status. lock(t->lock); t->cancelling = true; mb(); if (cur->cancelling) return -EDEADLK; unlock(t->lock); hrtimer_cancel(t->timer); t->cancelling = false; The store outside the critical section could overwrite a parallel requests t->cancelling assignment to true, to ensure the parallely executing callback observes its cancellation status. It would be necessary to clear this cancelling bit once hrtimer_cancel is done, but lack of serialization introduced races. Another option was explored where bpf_timer_start would clear the bit when (re)starting the timer under timer->lock. This would ensure serialized access to the cancelling bit, but may allow it to be cleared before in-flight hrtimer_cancel has finished executing, such that lockups can occur again. Thus, we choose an atomic counter to keep track of all outstanding cancellation requests and use it to prevent lockups in case callbacks attempt to cancel each other while executing in parallel. | |||||
| CVE-2024-42240 | 1 Linux | 1 Linux Kernel | 2024-08-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: x86/bhi: Avoid warning in #DB handler due to BHI mitigation When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set then entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls the clear_bhb_loop() before the TF flag is cleared. This causes the #DB handler (exc_debug_kernel()) to issue a warning because single-step is used outside the entry_SYSENTER_compat() function. To address this issue, entry_SYSENTER_compat() should use CLEAR_BRANCH_HISTORY after making sure the TF flag is cleared. The problem can be reproduced with the following sequence: $ cat sysenter_step.c int main() { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); } $ gcc -o sysenter_step sysenter_step.c $ ./sysenter_step Segmentation fault (core dumped) The program is expected to crash, and the #DB handler will issue a warning. Kernel log: WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160 ... RIP: 0010:exc_debug_kernel+0xd2/0x160 ... Call Trace: <#DB> ? show_regs+0x68/0x80 ? __warn+0x8c/0x140 ? exc_debug_kernel+0xd2/0x160 ? report_bug+0x175/0x1a0 ? handle_bug+0x44/0x90 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? exc_debug_kernel+0xd2/0x160 exc_debug+0x43/0x50 asm_exc_debug+0x1e/0x40 RIP: 0010:clear_bhb_loop+0x0/0xb0 ... </#DB> <TASK> ? entry_SYSENTER_compat_after_hwframe+0x6e/0x8d </TASK> [ bp: Massage commit message. ] | |||||