Total
263593 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-22303 | 1 Favethemes | 1 Houzez | 2024-09-20 | 8.8 High |
| Incorrect Privilege Assignment vulnerability in favethemes Houzez houzez allows Privilege Escalation.This issue affects Houzez: from n/a through 3.2.4. | ||||
| CVE-2024-43978 | 1 Superstorefinder | 1 Super Store Finder | 2024-09-20 | 9.3 Critical |
| Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in highwarden Super Store Finder allows SQL Injection.This issue affects Super Store Finder: from n/a before 6.9.8. | ||||
| CVE-2024-38380 | 2024-09-20 | 5.5 Medium | ||
| This vulnerability occurs when user-supplied input is improperly sanitized and then reflected back to the user's browser, allowing an attacker to execute arbitrary JavaScript in the context of the victim's browser session. | ||||
| CVE-2024-38812 | 1 Broadcom | 2 Vmware Cloud Foundation, Vmware Vcenter Server | 2024-09-20 | 9.8 Critical |
| The vCenter Server contains a heap-overflow vulnerability in the implementation of the DCERPC protocol. A malicious actor with network access to vCenter Server may trigger this vulnerability by sending a specially crafted network packet potentially leading to remote code execution. | ||||
| CVE-2024-41929 | 1 Takenaka Engineering | 9 Ahd04t-a Firmware, Ahd08t-a Firmware, Ahd16t-a Firmware and 6 more | 2024-09-20 | 8.8 High |
| Improper authentication vulnerability in multiple digital video recorders provided by TAKENAKA ENGINEERING CO., LTD. allows a remote authenticated attacker to execute an arbitrary OS command on the device or alter the device settings. | ||||
| CVE-2024-43778 | 1 Takenaka Engineering | 9 Ahd04t-a Firmware, Ahd08t-a Firmware, Ahd16t-a Firmware and 6 more | 2024-09-20 | 8.8 High |
| OS command injection vulnerability in multiple digital video recorders provided by TAKENAKA ENGINEERING CO., LTD. allows a remote authenticated attacker to execute an arbitrary OS command on the device or alter the device settings. | ||||
| CVE-2024-43985 | 2024-09-20 | 5.9 Medium | ||
| Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in MagePeople Team Bus Ticket Booking with Seat Reservation allows Stored XSS.This issue affects Bus Ticket Booking with Seat Reservation: from n/a through 5.3.5. | ||||
| CVE-2024-43995 | 2024-09-20 | 6.5 Medium | ||
| Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in sonalsinha21 Posterity allows Stored XSS.This issue affects Posterity: from n/a through 3.6. | ||||
| CVE-2024-44001 | 2024-09-20 | 6.5 Medium | ||
| Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in WP Royal Royal Elementor Addons allows Stored XSS.This issue affects Royal Elementor Addons: from n/a through 1.3.982. | ||||
| CVE-2024-45605 | 2024-09-20 | 6.5 Medium | ||
| Sentry is a developer-first error tracking and performance monitoring platform. An authenticated user delete the user issue alert notifications for arbitrary users given a know alert ID. A patch was issued to ensure authorization checks are properly scoped on requests to delete user alert notifications. Sentry SaaS users do not need to take any action. Self-Hosted Sentry users should upgrade to version 24.9.0 or higher. There are no known workarounds for this vulnerability. | ||||
| CVE-2024-45606 | 2024-09-20 | 7.1 High | ||
| Sentry is a developer-first error tracking and performance monitoring platform. An authenticated user can mute alert rules from arbitrary organizations and projects with a know rule ID. The user does not need to be a member of the organization or have permissions on the project. In our review, we have identified no instances where alerts have been muted by unauthorized parties. A patch was issued to ensure authorization checks are properly scoped on requests to mute alert rules. Authenticated users who do not have the necessary permissions are no longer able to mute alerts. Sentry SaaS users do not need to take any action. Self-Hosted Sentry users should upgrade to version **24.9.0** or higher. The rule mute feature was generally available as of 23.6.0 but users with early access may have had the feature as of 23.4.0. Affected users are advised to upgrade to version 24.9.0. There are no known workarounds for this vulnerability. | ||||
| CVE-2024-45682 | 1 Millbeck Communications | 1 Proroute H685t-w | 2024-09-20 | 8.8 High |
| There is a command injection vulnerability that may allow an attacker to inject malicious input on the device's operating system. | ||||
| CVE-2024-45803 | 1 Wireui | 1 Wireui | 2024-09-20 | N/A |
| Wire UI is a library of components and resources to empower Laravel and Livewire application development. A potential Cross-Site Scripting (XSS) vulnerability has been identified in the `/wireui/button` endpoint, specifically through the `label` query parameter. Malicious actors could exploit this vulnerability by injecting JavaScript into the `label` parameter, leading to the execution of arbitrary code in the victim's browser. The `/wireui/button` endpoint dynamically renders button labels based on user-provided input via the `label` query parameter. Due to insufficient sanitization or escaping of this input, an attacker can inject malicious JavaScript. By crafting such a request, an attacker can inject arbitrary code that will be executed by the browser when the endpoint is accessed. If exploited, this vulnerability could allow an attacker to execute arbitrary JavaScript code in the context of the affected website. This could lead to: **Session Hijacking**: Stealing session cookies, tokens, or other sensitive information. **User Impersonation**: Performing unauthorized actions on behalf of authenticated users. **Phishing**: Redirecting users to malicious websites. **Content Manipulation**: Altering the appearance or behavior of the affected page to mislead users or execute further attacks. The severity of this vulnerability depends on the context of where the affected component is used, but in all cases, it poses a significant risk to user security. This issue has been addressed in release versions 1.19.3 and 2.1.3. Users are advised to upgrade. There are no known workarounds for this vulnerability. | ||||
| CVE-2024-45816 | 2024-09-20 | 6.5 Medium | ||
| Backstage is an open framework for building developer portals. When using the AWS S3 or GCS storage provider for TechDocs it is possible to access content in the entire storage bucket. This can leak contents of the bucket that are not intended to be accessible, as well as bypass permission checks in Backstage. This has been fixed in the 1.10.13 release of the `@backstage/plugin-techdocs-backend` package. All users are advised to upgrade. There are no known workarounds for this vulnerability. | ||||
| CVE-2024-46718 | 2024-09-20 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: drm/xe: Don't overmap identity VRAM mapping Overmapping the identity VRAM mapping is triggering hardware bugs on certain platforms. Use 2M pages for the last unaligned (to 1G) VRAM chunk. v2: - Always use 2M pages for last chunk (Fei Yang) - break loop when 2M pages are used - Add assert for usable_size being 2M aligned v3: - Fix checkpatch | ||||
| CVE-2024-46756 | 2024-09-20 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: hwmon: (w83627ehf) Fix underflows seen when writing limit attributes DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. | ||||
| CVE-2024-46750 | 2024-09-20 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: PCI: Add missing bridge lock to pci_bus_lock() One of the true positives that the cfg_access_lock lockdep effort identified is this sequence: WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70 RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70 Call Trace: <TASK> ? __warn+0x8c/0x190 ? pci_bridge_secondary_bus_reset+0x5d/0x70 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? pci_bridge_secondary_bus_reset+0x5d/0x70 pci_reset_bus+0x1d8/0x270 vmd_probe+0x778/0xa10 pci_device_probe+0x95/0x120 Where pci_reset_bus() users are triggering unlocked secondary bus resets. Ironically pci_bus_reset(), several calls down from pci_reset_bus(), uses pci_bus_lock() before issuing the reset which locks everything *but* the bridge itself. For the same motivation as adding: bridge = pci_upstream_bridge(dev); if (bridge) pci_dev_lock(bridge); to pci_reset_function() for the "bus" and "cxl_bus" reset cases, add pci_dev_lock() for @bus->self to pci_bus_lock(). [bhelgaas: squash in recursive locking deadlock fix from Keith Busch: https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com] | ||||
| CVE-2024-46765 | 2024-09-20 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: ice: protect XDP configuration with a mutex The main threat to data consistency in ice_xdp() is a possible asynchronous PF reset. It can be triggered by a user or by TX timeout handler. XDP setup and PF reset code access the same resources in the following sections: * ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked * ice_vsi_rebuild() for the PF VSI - not protected * ice_vsi_open() - already rtnl-locked With an unfortunate timing, such accesses can result in a crash such as the one below: [ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14 [ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18 [Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms [ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001 [ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14 [ +0.394718] ice 0000:b1:00.0: PTP reset successful [ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ +0.000045] #PF: supervisor read access in kernel mode [ +0.000023] #PF: error_code(0x0000) - not-present page [ +0.000023] PGD 0 P4D 0 [ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1 [ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021 [ +0.000036] Workqueue: ice ice_service_task [ice] [ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice] [...] [ +0.000013] Call Trace: [ +0.000016] <TASK> [ +0.000014] ? __die+0x1f/0x70 [ +0.000029] ? page_fault_oops+0x171/0x4f0 [ +0.000029] ? schedule+0x3b/0xd0 [ +0.000027] ? exc_page_fault+0x7b/0x180 [ +0.000022] ? asm_exc_page_fault+0x22/0x30 [ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice] [ +0.000194] ice_free_tx_ring+0xe/0x60 [ice] [ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice] [ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice] [ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice] [ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice] [ +0.000145] ice_rebuild+0x18c/0x840 [ice] [ +0.000145] ? delay_tsc+0x4a/0xc0 [ +0.000022] ? delay_tsc+0x92/0xc0 [ +0.000020] ice_do_reset+0x140/0x180 [ice] [ +0.000886] ice_service_task+0x404/0x1030 [ice] [ +0.000824] process_one_work+0x171/0x340 [ +0.000685] worker_thread+0x277/0x3a0 [ +0.000675] ? preempt_count_add+0x6a/0xa0 [ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50 [ +0.000679] ? __pfx_worker_thread+0x10/0x10 [ +0.000653] kthread+0xf0/0x120 [ +0.000635] ? __pfx_kthread+0x10/0x10 [ +0.000616] ret_from_fork+0x2d/0x50 [ +0.000612] ? __pfx_kthread+0x10/0x10 [ +0.000604] ret_from_fork_asm+0x1b/0x30 [ +0.000604] </TASK> The previous way of handling this through returning -EBUSY is not viable, particularly when destroying AF_XDP socket, because the kernel proceeds with removal anyway. There is plenty of code between those calls and there is no need to create a large critical section that covers all of them, same as there is no need to protect ice_vsi_rebuild() with rtnl_lock(). Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp(). Leaving unprotected sections in between would result in two states that have to be considered: 1. when the VSI is closed, but not yet rebuild 2. when VSI is already rebuild, but not yet open The latter case is actually already handled through !netif_running() case, we just need to adjust flag checking a little. The former one is not as trivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of hardware interaction happens, this can make adding/deleting rings exit with an error. Luckily, VSI rebuild is pending and can apply new configuration for us in a managed fashion. Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to indicate that ice_x ---truncated--- | ||||
| CVE-2024-46760 | 2024-09-20 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: schedule rx work after everything is set up Right now it's possible to hit NULL pointer dereference in rtw_rx_fill_rx_status on hw object and/or its fields because initialization routine can start getting USB replies before rtw_dev is fully setup. The stack trace looks like this: rtw_rx_fill_rx_status rtw8821c_query_rx_desc rtw_usb_rx_handler ... queue_work rtw_usb_read_port_complete ... usb_submit_urb rtw_usb_rx_resubmit rtw_usb_init_rx rtw_usb_probe So while we do the async stuff rtw_usb_probe continues and calls rtw_register_hw, which does all kinds of initialization (e.g. via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on. Fix this by moving the first usb_submit_urb after everything is set up. For me, this bug manifested as: [ 8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped [ 8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status because I'm using Larry's backport of rtw88 driver with the NULL checks in rtw_rx_fill_rx_status. | ||||
| CVE-2024-46761 | 2024-09-20 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel crash when we try to hot-unplug/disable the PCIe switch/bridge from the PHB. The crash occurs because although the MSI data structure has been released during disable/hot-unplug path and it has been assigned with NULL, still during unregistration the code was again trying to explicitly disable the MSI which causes the NULL pointer dereference and kernel crash. The patch fixes the check during unregistration path to prevent invoking pci_disable_msi/msix() since its data structure is already freed. | ||||