Export limit exceeded: 357212 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Search

Search Results (357212 CVEs found)

CVE Vendors Products Updated CVSS v3.1
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-36784 1 Tenda 1 O3 Wireless Router 2026-06-10 7.5 High
Shenzhen Tenda Technology Co., Ltd Tenda O3 Wireless Router v1.0.0.5(4180) was discovered to contain a stack overflow in the ip parameter of the fromNetToolGet function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a HTTP request.
CVE-2026-36779 1 Tenda 1 O3 Wireless Router 2026-06-10 7.5 High
Shenzhen Tenda Technology Co., Ltd Tenda O3 Wireless Router v1.0.0.5(4180) was discovered to contain multiple stack overflows in the fromVirtualSer function via the puVar2, puVar1, __s2, __s1_00, and puVar3 parameters. These vulnerabilities allow attackers to cause a Denial of Service (DoS) via a crafted HTTP request.
CVE-2026-36727 1 Bookcars 1 Bookcars 2026-06-10 9.1 Critical
An insecure authentication vulnerability in the /api/social-sign-in endpoint of bookcars v8.3 allows attackers to bypass authentication via a forged JWT token.
CVE-2026-11853 1 Debian 1 Debusine 2026-06-10 6.5 Medium
Debusine is an integrated solution to build, distribute and maintain a Debian-based distribution. Debian source packages (.dsc) and upload artifacts (.changes) are manifest files that name the files that make up the artifact. The parser used to read these files in Debusine accepted arbitrary fully user-controlled paths. The mergeuploads task could be abused to create arbitrary symbolic links on a worker, overwriting any file that the worker user has access to.
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-46212 1 Linux 1 Linux Kernel 2026-06-10 8.8 High
In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: prevent use-after-free when deleting claims When batadv_bla_del_backbone_claims() removes all claims for a backbone, it does this by dropping the link entry in the hash list. This list entry itself was one of the references which need to be dropped at the same time via batadv_claim_put(). But the batadv_claim_put() must not be done before the last access to the claim object in this function. Otherwise the claim might be freed already by the batadv_claim_release() function before the list entry was dropped.
CVE-2026-46213 1 Linux 1 Linux Kernel 2026-06-10 7.8 High
In the Linux kernel, the following vulnerability has been resolved: HID: appletb-kbd: fix UAF in inactivity-timer cleanup path Commit 38224c472a03 ("HID: appletb-kbd: fix slab use-after-free bug in appletb_kbd_probe") added timer_delete_sync(&kbd->inactivity_timer) to both the probe close_hw error path and appletb_kbd_remove(), but the way it was wired in left the inactivity timer reachable during driver tear-down via two distinct windows. Window A -- put_device() before timer_delete_sync(): put_device(&kbd->backlight_dev->dev); timer_delete_sync(&kbd->inactivity_timer); The inactivity_timer softirq reads kbd->backlight_dev and calls backlight_device_set_brightness() -> mutex_lock(&ops_lock). If a concurrent hid_appletb_bl unbind drops the last devm reference between these two calls, the backlight_device is freed and the mutex_lock() touches freed memory. Window B -- backlight cleanup before hid_hw_stop(): if (kbd->backlight_dev) { timer_delete_sync(...); put_device(...); } hid_hw_close(hdev); hid_hw_stop(hdev); Even after Window A is closed, hid_hw_close()/hid_hw_stop() still run afterwards, so a late ".event" callback from the HID core (USB URB completion on real Apple hardware) can arrive after timer_delete_sync() drained the softirq but before put_device() drops the reference. That callback reaches reset_inactivity_timer(), which calls mod_timer() and re-arms the timer. The freshly re-armed timer can then fire on the about-to-be-freed backlight_device. Both windows produce the same KASAN slab-use-after-free: BUG: KASAN: slab-use-after-free in __mutex_lock+0x1aab/0x21c0 Read of size 8 at addr ffff88803ee9a108 by task swapper/0/0 Call Trace: <IRQ> __mutex_lock backlight_device_set_brightness appletb_inactivity_timer call_timer_fn run_timer_softirq handle_softirqs Allocated by task N: devm_backlight_device_register appletb_bl_probe Freed by task M: (concurrent hid_appletb_bl unbind path) Close both windows at once by reworking the tear-down in appletb_kbd_remove() and in the probe close_hw error path so that 1) hid_hw_close()/hid_hw_stop() run before the backlight cleanup, guaranteeing no further .event callback can fire and re-arm the timer, and 2) inside the "if (kbd->backlight_dev)" block, timer_delete_sync() runs before put_device(), so the softirq is drained before the final reference is dropped.
CVE-2026-46214 1 Linux 1 Linux Kernel 2026-06-10 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix accept queue count leak on transport mismatch virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listener to reject all new connections. Fix by moving sk_acceptq_added() to after the transport validation, matching the pattern used by vmci_transport and hyperv_transport.
CVE-2026-46215 1 Linux 1 Linux Kernel 2026-06-10 7.8 High
In the Linux kernel, the following vulnerability has been resolved: drm: Set old handle to NULL before prime swap in change_handle There was a potential race condition in change_handle. The ioctl briefly had a single object with two idr entries; a concurrent gem_close could delete the object and remove one of the handles while leaving the other one dangling, which could subsequently be dereferenced for a use-after-free. To fix this, do the same dance that gem_close itself does. (f6cd7daecff5 drm: Release driver references to handle before making it available again) First idr_replace the old handle to NULL. Later, if the prime operations are successful, actually close it. create_tail required a similar dance to avoid a similar problem. (bd46cece51a3 drm/gem: Fix race in drm_gem_handle_create_tail()) It idr_allocs the new handle with NULL, then swaps in the correct object later to avoid races. We don't need to do that here, since the only operations that could race are drm_prime, and change_handle holds the prime lock for the entire duration. v2: cleanups of error paths
CVE-2026-46216 1 Linux 1 Linux Kernel 2026-06-10 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: drm/xe/hdcp: Add NULL check for media_gt in intel_hdcp_gsc_check_status() When media GT is disabled via configfs, there is no allocation for media_gt, which is kept as NULL. In such scenario, intel_hdcp_gsc_check_status() results in a kernel pagefault error due to &gt->uc.gsc being evaluated as an invalid memory address. Fix that by introducing a NULL check on media_gt and bailing out early if so. While at it, also drop the NULL check for gsc, since it can't be NULL if media_gt is not NULL. v2: - Get address for gsc only after checking that gt is not NULL. (Shuicheng) - Drop the NULL check for gsc. (Shuicheng) v3: - Add "Fixes" and "Cc: <stable...>" tags. (Matt) (cherry picked from commit bfaf87e84ca3ca3f6e275f9ae56da47a8b55ffd1)
CVE-2026-46217 1 Linux 1 Linux Kernel 2026-06-10 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: Avoid overflow on msg bound check As pointed out by SDL, the previous condition may be vulnerable to overflow. (cherry picked from commit 3c5367d950140d4ec7af830b2268a5a6fdaa3885)
CVE-2026-46218 1 Linux 1 Linux Kernel 2026-06-10 7.1 High
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Add bounds checking to ib_{get,set}_value The uvd/vce/vcn code accesses the IB at predefined offsets without checking that the IB is large enough. Check the bounds here. The caller is responsible for making sure it can handle arbitrary return values. Also make the idx a uint32_t to prevent overflows causing the condition to fail.
CVE-2026-11232 4 Apple, Google, Linux and 1 more 4 Macos, Chrome, Linux Kernel and 1 more 2026-06-10 5.4 Medium
Inappropriate implementation in TabGroups in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to perform UI spoofing via malicious network traffic. (Chromium security severity: Low)
CVE-2026-11230 4 Apple, Google, Linux and 1 more 4 Macos, Chrome, Linux Kernel and 1 more 2026-06-10 8.8 High
Use after free in Extensions in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Low)
CVE-2026-11229 4 Apple, Google, Linux and 1 more 4 Macos, Chrome, Linux Kernel and 1 more 2026-06-10 6.1 Medium
Inappropriate implementation in Enterprise in Google Chrome prior to 149.0.7827.53 allowed a local attacker to perform privilege escalation via physical access to the device. (Chromium security severity: Low)
CVE-2026-46227 1 Linux 1 Linux Kernel 2026-06-10 7.8 High
In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 ("sctp: walk the list of asoc safely") was added for.
CVE-2026-46226 1 Linux 1 Linux Kernel 2026-06-10 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: spi: fsl: fix controller deregistration Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind.
CVE-2026-46225 1 Linux 1 Linux Kernel 2026-06-10 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: spi: rspi: fix controller deregistration Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind.
CVE-2026-11653 4 Apple, Google, Linux and 1 more 4 Macos, Chrome, Linux Kernel and 1 more 2026-06-10 6.5 Medium
Inappropriate implementation in Extensions in Google Chrome prior to 149.0.7827.103 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: High)