Export limit exceeded: 361357 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 361357 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (361357 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-36802 | 1 Tenda | 1 Pw201a | 2026-06-10 | 7.5 High |
| Shenzhen Tenda Technology Co., Ltd Tenda PW201A v1.0.5 was discovered to contain a buffer overflow in the page parameter of the SafeMacFilter function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted HTTP request. | ||||
| CVE-2026-36792 | 1 Tenda | 1 W3 Wireless Router | 2026-06-10 | 7.5 High |
| Shenzhen Tenda Technology Co., Ltd Tenda W3 Wireless Router v1.0.0.3(2204) was discovered to contain a stack overflow in the wl_radio parameter of the formWifiRadioSet function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted HTTP request. | ||||
| CVE-2026-36807 | 1 Tenda | 1 W15e | 2026-06-10 | 7.5 High |
| Shenzhen Tenda Technology Co., Ltd Tenda W15E v15.11.0.10 was discovered to contain a buffer overflow in the webAuthUserPwd parameter of the formAddWebAuthUser function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted HTTP request. | ||||
| CVE-2026-36818 | 1 Tenda | 1 W20e | 2026-06-10 | 7.5 High |
| Shenzhen Tenda Technology Co., Ltd Tenda W20E v15.11.0.6 was discovered to contain a buffer overflow in the wewifiWhiteUserInfo parameter of the formAddWewifiWhiteUser function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted HTTP request. | ||||
| CVE-2026-36772 | 1 Tenda | 1 W3 Wireless Router | 2026-06-10 | 6.5 Medium |
| Shenzhen Tenda Technology Co., Ltd Tenda W3 Wireless Router v1.0.0.3(2204) was discovered to contain a stack overflow in the wl_radio parameter of the formwrlSSIDget function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input. | ||||
| CVE-2026-36722 | 1 Bookcars | 1 Bookcars | 2026-06-10 | 5.4 Medium |
| An authenticated arbitrary file upload vulnerability in the /api/create-car-image component of bookcars v8.3 allows attackers to execute arbitrary code via uploading a crafted file. | ||||
| CVE-2026-36810 | 1 Tenda | 1 W15e | 2026-06-10 | 7.5 High |
| Shenzhen Tenda Technology Co., Ltd Tenda W15E v15.11.0.10 was discovered to contain a buffer overflow in the gotoUrl parameter of the formPortalAuth function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted HTTP request. | ||||
| CVE-2026-36815 | 1 Tenda | 1 W15e | 2026-06-10 | 7.5 High |
| Shenzhen Tenda Technology Co., Ltd Tenda W15E v15.11.0.10 was discovered to contain a buffer overflow in the hostname parameter of the formSetNetCheckTools function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted HTTP request. | ||||
| CVE-2026-36726 | 1 Bookcars | 1 Bookcars | 2026-06-10 | 5.3 Medium |
| An arbitrary file deletion vulnerability in the /api/delete-temp-license/{file} endpoint of bookcars v8.3 allows unauthenticated attackers to delete arbitrary files via supplying directory traversal sequences. | ||||
| CVE-2026-36777 | 1 Tenda | 1 W3 Wireless Router | 2026-06-10 | 6.5 Medium |
| Shenzhen Tenda Technology Co., Ltd Tenda W3 Wireless Router v1.0.0.3(2204) was discovered to contain a stack overflow in the param_1 parameter of the formSetCfm function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted HTTP request. | ||||
| CVE-2026-36799 | 1 Tenda | 1 G0 | 2026-06-10 | 7.5 High |
| Shenzhen Tenda Technology Co., Ltd Tenda G0 v15.11.0.5 was discovered to contain a buffer overflow in the portalAuth parameter of the formPortalAuth function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted HTTP request. | ||||
| CVE-2026-36801 | 1 Tenda | 1 G0 | 2026-06-10 | 7.5 High |
| Shenzhen Tenda Technology Co., Ltd Tenda G0 v15.11.0.5 was discovered to contain a buffer overflow in the IPMacBindRule parameter of the formIPMacBindAdd function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted HTTP request. | ||||
| CVE-2026-11852 | 1 Debian | 1 Debusine | 2026-06-10 | 6.5 Medium |
| Debusine is an integrated solution to build, distribute and maintain a Debian-based distribution. Files managed by debusine are organized into artifacts. The endpoints that create and delete relationships between artifacts enforced no permissions checks beyond being able to see the artifacts in question. | ||||
| CVE-2026-46242 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: eventpoll: fix ep_remove struct eventpoll / struct file UAF ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays. | ||||
| CVE-2026-46149 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show() target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered. Commit 27e06650a5ea ("scsi: target: target_core_configfs: Add length check to avoid buffer overflow") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here. | ||||
| CVE-2026-46146 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3() The convert_chmap_v3() has a loop with its increment size of cs_desc->wLength, but we forgot to validate cs_desc->wLength itself, which may lead to potential endless loop by a malformed descriptor. Add a proper size check to abort the loop for plugging the hole. | ||||
| CVE-2026-46148 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: spi: microchip-core-qspi: control built-in cs manually The coreQSPI IP supports only a single chip select, which is automagically operated by the hardware - set low when the transmit buffer first gets written to and set high when the number of bytes written to the TOTALBYTES field of the FRAMES register have been sent on the bus. Additional devices must use GPIOs for their chip selects. It was reported to me that if there are two devices attached to this QSPI controller that the in-built chip select is set low while linux tries to access the device attached to the GPIO. This went undetected as the boards that connected multiple devices to the SPI controller all exclusively used GPIOs for chip selects, not relying on the built-in chip select at all. It turns out that this was because the built-in chip select, when controlled automagically, is set low when active and high when inactive, thereby ruling out its use for active-high devices or devices that need to transmit with the chip select disabled. Modify the driver so that it controls chip select directly, retaining the behaviour for mem_ops of setting the chip select active for the entire duration of the transfer in the exec_op callback. For regular transfers, implement the set_cs callback for the core to use. As part of this, the existing setup callback, mchp_coreqspi_setup_op(), is removed. Modifying the CLKIDLE field is not safe to do during operation when there are multiple devices, so this code is removed entirely. Setting the MASTER and ENABLE fields is something that can be done once at probe, it doesn't need to be re-run for each device. Instead the new setup callback sets the built-in chip select to its inactive state for active-low devices, as the reset value of the chip select in software controlled mode is low. | ||||
| CVE-2026-46147 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix pin leak and publication ordering in __pkvm_init_vcpu() Two bugs exist in the vCPU initialisation path: 1. If a check fails after hyp_pin_shared_mem() succeeds, the cleanup path jumps to 'unlock' without calling unpin_host_vcpu() or unpin_host_sve_state(), permanently leaking pin references on the host vCPU and SVE state pages. Extract a register_hyp_vcpu() helper that performs the checks and the store. When register_hyp_vcpu() returns an error, call unpin_host_vcpu() and unpin_host_sve_state() inline before falling through to the existing 'unlock' label. 2. register_hyp_vcpu() publishes the new vCPU pointer into 'hyp_vm->vcpus[]' with a bare store, allowing a concurrent caller of pkvm_load_hyp_vcpu() to observe a partially initialised vCPU object. Ensure the store uses smp_store_release() and the load uses smp_load_acquire(). While 'vm_table_lock' currently serialises the store and the load, these barriers ensure the reader sees the fully initialised 'hyp_vcpu' object even if there were a lockless path or if the lock's own ordering guarantees were insufficient for nested object initialization. | ||||
| CVE-2026-46145 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Validate rx_hash_key_len Sashiko points out that rx_hash_key_len comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow. | ||||
| CVE-2026-46144 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Fix error unwind in mana_ib_create_qp_rss() Sashiko points out that mana_ib_cfg_vport_steering() is leaked, the normal destroy path cleans it up. | ||||