Total
31934 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-50134 | 1 Linux | 1 Linux Kernel | 2024-11-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a "memcpy: detected field-spanning write error" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept. | |||||
| CVE-2024-50072 | 1 Linux | 1 Linux Kernel | 2024-11-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ] | |||||
| CVE-2024-44931 | 1 Linux | 1 Linux Kernel | 2024-11-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: gpio: prevent potential speculation leaks in gpio_device_get_desc() Userspace may trigger a speculative read of an address outside the gpio descriptor array. Users can do that by calling gpio_ioctl() with an offset out of range. Offset is copied from user and then used as an array index to get the gpio descriptor without sanitization in gpio_device_get_desc(). This change ensures that the offset is sanitized by using array_index_nospec() to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. | |||||
| CVE-2024-49973 | 1 Linux | 1 Linux Kernel | 2024-11-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it. | |||||
| CVE-2024-50082 | 1 Linux | 1 Linux Kernel | 2024-11-08 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait(). | |||||
| CVE-2023-29115 | 1 Enelx | 2 Waybox Pro, Waybox Pro Firmware | 2024-11-08 | N/A | 6.5 MEDIUM |
| In certain conditions a request directed to the Waybox Enel X Web management application could cause a denial-of-service (e.g. reboot). | |||||
| CVE-2023-29116 | 1 Enelx | 2 Waybox Pro, Waybox Pro Firmware | 2024-11-08 | N/A | 4.3 MEDIUM |
| Under certain conditions, through a request directed to the Waybox Enel X web management application, information like Waybox OS version or service configuration details could be obtained. | |||||
| CVE-2024-10329 | 1 G5plus | 1 Ultimate Bootstrap Elements For Elementor | 2024-11-08 | N/A | 4.3 MEDIUM |
| The Ultimate Bootstrap Elements for Elementor plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.4.6 via the 'ube_get_page_templates' function. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract sensitive data including the contents of templates that are private. | |||||
| CVE-2024-30106 | 1 Hcltech | 1 Connections | 2024-11-08 | N/A | 4.3 MEDIUM |
| HCL Connections is vulnerable to an information disclosure vulnerability, due to an IBM WebSphere Application Server error, which could allow a user to obtain sensitive information they are not entitled to due to the improper handling of request data. | |||||
| CVE-2023-37765 | 1 Gpac | 1 Gpac | 2024-11-08 | N/A | 5.5 MEDIUM |
| GPAC v2.3-DEV-rev381-g817a848f6-master was discovered to contain a segmentation violation in the gf_dump_vrml_sffield function at /lib/libgpac.so. | |||||
| CVE-2023-37766 | 1 Gpac | 1 Gpac | 2024-11-08 | N/A | 5.5 MEDIUM |
| GPAC v2.3-DEV-rev381-g817a848f6-master was discovered to contain a segmentation violation in the gf_isom_remove_user_data function at /lib/libgpac.so. | |||||
| CVE-2024-38204 | 1 Microsoft | 1 Azure Functions | 2024-11-08 | N/A | 6.5 MEDIUM |
| Improper Access Control in Imagine Cup allows an authorized attacker to elevate privileges over a network. | |||||
| CVE-2024-10319 | 1 Wpxpro | 1 Xpro Addons For Elementor | 2024-11-08 | N/A | 4.3 MEDIUM |
| The 140+ Widgets | Xpro Addons For Elementor – FREE plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.4.6 via the render function in widgets/content-toggle/layout/frontend.php. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract sensitive private, pending, and draft template data. | |||||
| CVE-2024-38139 | 1 Microsoft | 1 Dataverse | 2024-11-08 | N/A | 8.8 HIGH |
| Improper authentication in Microsoft Dataverse allows an authorized attacker to elevate privileges over a network. | |||||
| CVE-2024-38408 | 1 Qualcomm | 470 315 5g Iot Modem, 315 5g Iot Modem Firmware, Aqt1000 and 467 more | 2024-11-08 | N/A | 9.1 CRITICAL |
| Cryptographic issue when a controller receives an LMP start encryption command under unexpected conditions. | |||||
| CVE-2024-50136 | 1 Linux | 1 Linux Kernel | 2024-11-08 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Unregister notifier on eswitch init failure It otherwise remains registered and a subsequent attempt at eswitch enabling might trigger warnings of the sort: [ 682.589148] ------------[ cut here ]------------ [ 682.590204] notifier callback eswitch_vport_event [mlx5_core] already registered [ 682.590256] WARNING: CPU: 13 PID: 2660 at kernel/notifier.c:31 notifier_chain_register+0x3e/0x90 [...snipped] [ 682.610052] Call Trace: [ 682.610369] <TASK> [ 682.610663] ? __warn+0x7c/0x110 [ 682.611050] ? notifier_chain_register+0x3e/0x90 [ 682.611556] ? report_bug+0x148/0x170 [ 682.611977] ? handle_bug+0x36/0x70 [ 682.612384] ? exc_invalid_op+0x13/0x60 [ 682.612817] ? asm_exc_invalid_op+0x16/0x20 [ 682.613284] ? notifier_chain_register+0x3e/0x90 [ 682.613789] atomic_notifier_chain_register+0x25/0x40 [ 682.614322] mlx5_eswitch_enable_locked+0x1d4/0x3b0 [mlx5_core] [ 682.614965] mlx5_eswitch_enable+0xc9/0x100 [mlx5_core] [ 682.615551] mlx5_device_enable_sriov+0x25/0x340 [mlx5_core] [ 682.616170] mlx5_core_sriov_configure+0x50/0x170 [mlx5_core] [ 682.616789] sriov_numvfs_store+0xb0/0x1b0 [ 682.617248] kernfs_fop_write_iter+0x117/0x1a0 [ 682.617734] vfs_write+0x231/0x3f0 [ 682.618138] ksys_write+0x63/0xe0 [ 682.618536] do_syscall_64+0x4c/0x100 [ 682.618958] entry_SYSCALL_64_after_hwframe+0x4b/0x53 | |||||
| CVE-2023-21405 | 1 Axis | 11 A1001, A1001 Firmware, A1210 \(-b\) and 8 more | 2024-11-08 | N/A | 6.5 MEDIUM |
| Knud from Fraktal.fi has found a flaw in some Axis Network Door Controllers and Axis Network Intercoms when communicating over OSDP, highlighting that the OSDP message parser crashes the pacsiod process, causing a temporary unavailability of the door-controlling functionalities meaning that doors cannot be opened or closed. No sensitive or customer data can be extracted as the Axis device is not further compromised. Please refer to the Axis security advisory for more information, mitigation and affected products and software versions. | |||||
| CVE-2023-21410 | 1 Axis | 1 License Plate Verifier | 2024-11-08 | N/A | 8.8 HIGH |
| User provided input is not sanitized on the AXIS License Plate Verifier specific “api.cgi” allowing for arbitrary code execution. | |||||
| CVE-2023-21411 | 1 Axis | 1 License Plate Verifier | 2024-11-08 | N/A | 8.8 HIGH |
| User provided input is not sanitized in the “Settings > Access Control” configuration interface allowing for arbitrary code execution. | |||||
| CVE-2023-21416 | 1 Axis | 2 Axis Os, Axis Os 2022 | 2024-11-08 | N/A | 6.5 MEDIUM |
| Sandro Poppi, member of the AXIS OS Bug Bounty Program, has found that the VAPIX API dynamicoverlay.cgi was vulnerable to a Denial-of-Service attack allowing for an attacker to block access to the overlay configuration page in the web interface of the Axis device. This flaw can only be exploited after authenticating with an operator- or administrator-privileged service account however the impact is equal. Axis has released patched AXIS OS versions for the highlighted flaw. Please refer to the Axis security advisory for more information and solution. | |||||