Export limit exceeded: 83492 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (83492 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-36793 | 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 multiple stack overflows in the formwrlSSIDset function via the mit_ssid and mis_ssid_index parameters. These vulnerabilities allow attackers to cause a Denial of Service (DoS) via a crafted HTTP request. | ||||
| CVE-2026-36794 | 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 multiple stack overflows in the R7WebsSecurityHandler function via the username and password parameters. These vulnerabilities allow attackers to cause a Denial of Service (DoS) via a crafted HTTP request. | ||||
| 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-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-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-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-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-46176 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix error path fall-through in mlx5_ib_dev_res_srq_init() mlx5_ib_dev_res_srq_init() allocates two SRQs, s0 and s1. When ib_create_srq() fails for s1, the error branch destroys s0 but falls through and unconditionally assigns the freed s0 and the ERR_PTR s1 to devr->s0 and devr->s1. This leads to several problems: the lock-free fast path checks "if (devr->s1) return 0;" and treats the ERR_PTR as already initialised; users in mlx5_ib_create_qp() dereference the freed SRQ or ERR_PTR via to_msrq(devr->s0)->msrq.srqn; and mlx5_ib_dev_res_cleanup() dereferences the ERR_PTR and double-frees s0 on teardown. Fix by adding the same `goto unlock` in the s1 failure path. | ||||
| CVE-2026-46175 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: f2fs: fix fsck inconsistency caused by FGGC of node block During FGGC node block migration, fsck may incorrectly treat the migrated node block as fsync-written data. The reproduction scenario: root@vm:/mnt/f2fs# seq 1 2048 | xargs -n 1 ./test_sync // write inline inode and sync root@vm:/mnt/f2fs# rm -f 1 root@vm:/mnt/f2fs# sync root@vm:/mnt/f2fs# f2fs_io gc_range // move data block in sync mode and not write CP SPO, "fsck --dry-run" find inode has already checkpointed but still with DENT_BIT_SHIFT set The root cause is that GC does not clear the dentry mark and fsync mark during node block migration, leading fsck to misinterpret them as user-issued fsync writes. In BGGC mode, node block migration is handled by f2fs_sync_node_pages(), which guarantees the dentry and fsync marks are cleared before writing. This patch move the set/clear of the fsync|dentry marks into __write_node_folio to make the logic clearer, and ensures the fsync|dentry mark is cleared in FGGC. | ||||
| CVE-2026-46177 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: ipmi: Add limits to event and receive message requests The driver would just fetch events and receive messages until the BMC said it was done. To avoid issues with BMCs that never say they are done, add a limit of 10 fetches at a time. In addition, an si interface has an attn state it can return from the hardware which is supposed to cause a flag fetch to see if the driver needs to fetch events or message or a few other things. If the attn bit gets stuck, it's a similar problem. So allow messages in between flag fetches so the driver itself doesn't get stuck. This is a more general fix than the previous fix for the specific bad BMC, but should fix the more general issue of a BMC that won't stop saying it has data. This has been there from the beginning of the driver. It's not a bug per-se, but it is accounting for bugs in BMCs. | ||||
| CVE-2026-46166 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use safe list iteration in radar detect work The call to ieee80211_dfs_cac_cancel can cause the iterated chanctx to be freed and removed from the list. Guard against this to avoid a slab-use-after-free error. | ||||
| CVE-2026-46164 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free in create_space_info_sub_group() error path When kobject_init_and_add() fails, the call chain is: create_space_info_sub_group() -> btrfs_sysfs_add_space_info_type() -> kobject_init_and_add() -> failure -> kobject_put(&sub_group->kobj) -> space_info_release() -> kfree(sub_group) Then control returns to create_space_info_sub_group(), where: btrfs_sysfs_add_space_info_type() returns error -> kfree(sub_group) Thus, sub_group is freed twice. Keep parent->sub_group[index] = NULL for the failure path, but after btrfs_sysfs_add_space_info_type() has called kobject_put(), let the kobject release callback handle the cleanup. | ||||
| CVE-2026-46162 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ice: fix double free in ice_sf_eth_activate() error path When auxiliary_device_add() fails, ice_sf_eth_activate() jumps to aux_dev_uninit and calls auxiliary_device_uninit(&sf_dev->adev). The device release callback ice_sf_dev_release() frees sf_dev, but the current error path falls through to sf_dev_free and calls kfree(sf_dev) again, causing a double free. Keep kfree(sf_dev) for the auxiliary_device_init() failure path, but avoid falling through to sf_dev_free after auxiliary_device_uninit(). | ||||
| CVE-2026-46232 | 1 Linux | 1 Linux Kernel | 2026-06-10 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: HID: playstation: Clamp num_touch_reports A device would never lie about the number of touch reports would it? If it does the loop in dualshock4_parse_report will read off the end of the touch_reports array, up to about 2 KiB for the maximum number of 256 loop iteraions. The data that is read is emitted via evdev if the DS4_TOUCH_POINT_INACTIVE bit happens to be set. Protect against this by clamping the num_touch_reports value provided by the device to the maximum size of the touch_reports array. | ||||