Export limit exceeded: 421002 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (421002 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-3384 | 1 Redhat | 1 Quay | 2026-08-06 | 5.4 Medium |
| A flaw was found in the Quay registry. While the image labels created through Quay undergo validation both in the UI and backend by applying a regex (validation.py), the same validation is not performed when the label comes from an image. This flaw allows an attacker to publish a malicious image to a public registry containing a script that can be executed via Cross-site scripting (XSS). | ||||
| CVE-2026-64603 | 1 Linux | 1 Linux Kernel | 2026-08-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel-hid: Protect ACPI notify handler against recursion Since commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on all CPUs") ACPI notify handlers like the intel-hid notify_handler() may run on multiple CPU cores racing with themselves. On convertibles and detachables (matched by DMI chassis-type 31 and 32 in dmi_auto_add_switch[]) the SW_TABLET_MODE input device is registered lazily from notify_handler() on the first tablet-mode event, via intel_hid_switches_setup(). When two such events race on different CPUs both can pass the !priv->switches check and register the priv->switches input device twice, resulting in a duplicate sysfs entry and a subsequent NULL pointer dereference. This is the same class of bug fixed by commit e075c3b13a0a ("platform/x86: intel-vbtn: Protect ACPI notify handler against recursion") for the sibling intel-vbtn driver. Protect intel-hid notify_handler() from racing with itself with a mutex to fix this. | ||||
| CVE-2026-64595 | 1 Linux | 1 Linux Kernel | 2026-08-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: HID: hid-lenovo-go: cancel cfg_setup work in hid_go_cfg_remove() hid_go_cfg_probe() initialises drvdata.go_cfg_setup and schedules it to run 2 ms later: INIT_DELAYED_WORK(&drvdata.go_cfg_setup, &cfg_setup); schedule_delayed_work(&drvdata.go_cfg_setup, msecs_to_jiffies(2)); cfg_setup() dereferences drvdata.hdev to issue MCU command requests. hid_go_cfg_remove() tears down sysfs and stops the HID device, but never drains the delayed work. If the device is unbound within the 2 ms scheduling delay (a probe failure rolling back via remove, or a fast rmmod after probe), the work fires after hid_destroy_device() has dropped its reference and released the underlying hdev struct, leaving cfg_setup() with a stale drvdata.hdev pointer. Mirror the sibling driver hid-lenovo-go-s.c, whose hid_gos_cfg_remove() already calls cancel_delayed_work_sync() on its analogous work, and drain go_cfg_setup at the top of hid_go_cfg_remove(). The cancel must come before guard(mutex)(&drvdata.cfg_mutex) because cfg_setup() acquires that mutex; reversing the order would deadlock. | ||||
| CVE-2026-65458 | 2 Chouby, Wordpress | 2 Polylang, Wordpress | 2026-08-06 | 4.3 Medium |
| Exposure of Sensitive System Information to an Unauthorized Control Sphere vulnerability in Chouby Polylang and Chouby Polylang Pro allows Retrieve Embedded Sensitive Data. This issue affects Polylang: through 3.8.5; Polylang Pro: through 3.8.5. | ||||
| CVE-2026-64591 | 1 Linux | 1 Linux Kernel | 2026-08-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Avoid WARNING in sva unbind path The Intel IOMMU driver allows SVA on devices even if they do not support PCI/PRI. Commit 39c20c4e83b9 ("iommu/vt-d: Only handle IOPF for SVA when PRI is supported") modified the SVA bind path to allow this configuration by skipping IOPF enablement when PRI is missing. However, it failed to update the unbind path. This creates an imbalance: the unbind path attempts to disable IOPF for a device that never had it enabled, triggering a WARNING in intel_iommu_disable_iopf(): WARNING: drivers/iommu/intel/iommu.c:3475 at intel_iommu_disable_iopf+0x4f/0x90d Call Trace: <TASK> blocking_domain_set_dev_pasid+0x50/0x70 iommu_detach_device_pasid+0x89/0xc0 iommu_sva_unbind_device+0x73/0x150 xe_vm_close_and_put+0x4d2/0x1200 [xe] Fix this by bypassing IOPF operations for SVA domains on non-PRI hardware in both the bind and unbind paths. | ||||
| CVE-2026-64602 | 1 Linux | 1 Linux Kernel | 2026-08-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: iio: adc: spear: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: "spear_adc_probe() in drivers/iio/adc/spear_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in spear_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, spear_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ spear_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access." Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq(). | ||||
| CVE-2026-51992 | 1 Clickhouse | 1 Clickhouse | 2026-08-06 | 9.1 Critical |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. ClickHouse's PostgreSQL integration intentionally allows users with valid PostgreSQL credentials to execute queries against a remote PostgreSQL server. No vulnerability in ClickHouse is exploited; code execution occurs on the downstream PostgreSQL server using credentials explicitly provided by the user with specific pg_execute_server_program permission, exploiting a feature that was wrongly reported as CVE-2019-9193 in PostgreSQL (https://www.postgresql.org/about/news/cve-2019-9193-not-a-security-vulnerability-1935/). | ||||
| CVE-2026-64592 | 1 Linux | 1 Linux Kernel | 2026-08-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: riscv: mm: Unconditionally sfence.vma for spurious fault Svvptc does not guarantee that it's safe to just return here. Since we have already cleared our bit, if, theoretically, the bounded timeframe for the accessed page to become valid still hasn't happened after sret, we could fault again and actually crash. Hopefully, these spurious faults should be rare enough that this is an acceptable slowdown. | ||||
| CVE-2026-64594 | 1 Linux | 1 Linux Kernel | 2026-08-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: initialize reset_work at allocation time ffs_fs_kill_sb() unconditionally calls cancel_work_sync() on ffs->reset_work when a functionfs instance is unmounted: ffs_data_reset(ffs); cancel_work_sync(&ffs->reset_work); However ffs->reset_work is only ever initialized via INIT_WORK() in ffs_func_set_alt() and ffs_func_disable(), and only on the FFS_DEACTIVATED path. That state is reached solely by ffs_data_closed() when the instance is mounted with the "no_disconnect" option, so for the common case (no "no_disconnect", or mounted and unmounted without ever being deactivated) reset_work is never initialized. ffs_data_new() allocates the ffs_data with kzalloc_obj() and does not initialize reset_work, and ffs_data_reset()/ffs_data_clear() do not touch it either, so reset_work.func is left NULL. cancel_work_sync() on such a work then trips the WARN_ON(!work->func) guard in __flush_work(): WARNING: kernel/workqueue.c:4301 at __flush_work+0x330/0x360, CPU#3: umount Call trace: __flush_work cancel_work_sync ffs_fs_kill_sb [usb_f_fs] deactivate_locked_super deactivate_super cleanup_mnt __cleanup_mnt task_work_run exit_to_user_mode_loop el0_svc On older kernels cancel_work_sync() on a zero-initialized work struct was a silent no-op, which hid the missing initialization. Initialize reset_work once in ffs_data_new() so it is always valid for the lifetime of the ffs_data, and drop the now-redundant INIT_WORK() calls from the two deactivation paths. | ||||
| CVE-2026-64596 | 1 Linux | 1 Linux Kernel | 2026-08-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: libfs: set SB_I_NOEXEC and SB_I_NODEV by default in init_pseudo() Since commit 1e7ab6f67824 ("anon_inode: rework assertions"), path_noexec() warns when an anonymous-inode file is mmap'd from a superblock that has not set SB_I_NOEXEC. dma-buf backs its files this way and never set the flag, so mmap of any exported buffer trips the warning on a CONFIG_DEBUG_VFS=y kernel: WARNING: CPU: 11 PID: 121813 at fs/exec.c:118 path_noexec+0x47/0x50 do_mmap+0x2b5/0x680 vm_mmap_pgoff+0x129/0x210 ksys_mmap_pgoff+0x177/0x240 __x64_sys_mmap+0x33/0x70 init_pseudo() sets up internal SB_NOUSER mounts that are never path-reachable. Set both flags here so every pseudo filesystem gets them by default instead of each caller setting them. SB_I_NODEV is inert for unreachable mounts. SB_I_NOEXEC has one visible effect: an executable mapping of a pseudo-fs fd, such as a dma-buf, now fails with -EPERM, which is the invariant the assertion enforces. No in-tree caller maps these executable. Reproduce on CONFIG_DEBUG_VFS=y: make -C tools/testing/selftests/dmabuf-heaps sudo ./tools/testing/selftests/dmabuf-heaps/dmabuf-heap -t system | ||||
| CVE-2026-64589 | 1 Linux | 1 Linux Kernel | 2026-08-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix NULL-deref on adapter registration failure If adapter registration ever fails the release callback would trigger a NULL-pointer dereference as the completion struct has not been initialised. Note that before the offending commit this would instead have resulted in a minor memory leak of the adapter name. | ||||
| CVE-2023-7355 | 2026-08-06 | N/A | ||
| Erroneously reserved under wrong year by automation defect; never assigned. | ||||
| CVE-2023-7354 | 2026-08-06 | N/A | ||
| Erroneously reserved under wrong year by automation defect; never assigned. | ||||
| CVE-2023-7353 | 2026-08-06 | N/A | ||
| Erroneously reserved under wrong year by automation defect; never assigned. | ||||
| CVE-2026-8400 | 1 Ibm | 2 Websphere Application Server, Websphere Application Server Liberty | 2026-08-06 | 8.1 High |
| IBM WebSphere Application Server 8.5, and 9.0 and IBM WebSphere Application Server - Liberty Continuous delivery has a flaw in the ORB component in IBM SDK, Java Technology Edition, may allow a malicious IIOP server to induce loading and instantation of arbitrary classes. | ||||
| CVE-2026-44945 | 1 Suse | 1 Rancher | 2026-08-06 | 9.1 Critical |
| A privilege escalation vulnerability exists in Rancher's impersonation middleware (pkg/auth/requests/impersonate.go). An authenticated Rancher user with the default user global role can gain full administrative access to the Rancher control plane and transitively to all downstream clusters it manages. This issue affects Rancher: from 2.11.0 before 2.11.16, from 2.12.0 before 2.12.12, from 2.13.0 before 2.13.8, and from 2.14.0 before 2.14.2. | ||||
| CVE-2026-55997 | 1 Rancher | 1 Rancher | 2026-08-06 | 8.8 High |
| Rancher issues long-lived registration tokens to authenticate nodes and agents joining a downstream cluster. These tokens were stored and exposed in plaintext with no expiration, so a malicious user could obtain one either through the Rancher API, etcd, stored automation, or direct file access on a node, and could use it at any time to register a rogue node into the cluster. | ||||
| CVE-2026-24076 | 1 Qualcomm | 105 Aqt1000, Aqt1000 Firmware, Cologne and 102 more | 2026-08-06 | 6.7 Medium |
| Memory Corruption when processing registry values with incorrect types using a direct query method. | ||||
| CVE-2023-54389 | 2026-08-06 | N/A | ||
| Erroneously reserved under wrong year by automation defect; never assigned. | ||||
| CVE-2023-54388 | 2026-08-05 | N/A | ||
| Erroneously reserved under wrong year by automation defect; never assigned. | ||||