Export limit exceeded: 374108 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (374108 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-68959 | 2026-08-25 | N/A | ||
| SKYSEA Client View and SKYMEC IT Manager contain a path traversal vulnerability. If this vulnerability is exploited, an attacker who can log in to a Windows system on which the affected product is installed may be able to execute arbitrary code on another Windows system that has the affected products installed and can receive UDP packets from that system. Note that this vulnerability is due to an incomplete fix for CVE-2024-41726. | ||||
| CVE-2026-74621 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix sk_buff leak when the header checks reject a packet tcf_ct_handle_fragments() runs its header sanity checks before handing anything to the defragmentation engine: if (family == NFPROTO_IPV4) err = tcf_ct_ipv4_is_fragment(skb, &frag); else err = tcf_ct_ipv6_is_fragment(skb, &frag); if (err || !frag) return err; tcf_ct_ipv4_is_fragment() returns -EINVAL or -ENOMEM; tcf_ct_ipv6_is_fragment() adds -EPROTO when ipv6_find_hdr() fails. None of them frees or queues the skb, so on that path the caller still owns it. tcf_ct_act() however funnels every non-zero return into the ownership-transfer exit: err = tcf_ct_handle_fragments(net, skb, family, p->zone, &defrag); if (err) goto out_frag; ... out_frag: if (err != -EINPROGRESS) tcf_action_inc_drop_qstats(&c->common); return TC_ACT_CONSUMED; TC_ACT_CONSUMED means the action took ownership of the skb, so no caller frees it - sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for that verdict. The skb is therefore orphaned: one sk_buff plus its data buffer is leaked per malformed packet, unbounded. Note the drop counter is already incremented for these errors, so the statistics claim a drop that never happens. Three different ownership states reach out_frag: today - the skb may be queued by the defrag engine (-EINPROGRESS), already freed by nf_ct_handle_fragments(), or still owned by us. Tell the caller which of those it is, and free the packet ourselves in the last case, which restores the TC_ACT_SHOT behaviour that predated the Fixes: commit. Reproduced on v7.2-rc6 with a 54-byte frame carrying a 40-byte IPv6 header with nexthdr = 0 (hop-by-hop) and nothing after it, on a clsact ingress chain with "action ct". kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet; with this patch it reports none. | ||||
| CVE-2026-19542 | 2026-08-25 | 4.2 Medium | ||
| A flaw was found in glibc. An out-of-bounds array write vulnerability exists within the `tdelete` function. This issue occurs due to incorrect management of array sizes, which can lead to memory corruption. A local attacker with low privileges could potentially exploit this to cause a denial of service or disclose sensitive information. | ||||
| CVE-2026-74615 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: vxlan: do not arm the ageing timer on a device that is down vxlan_changelink() arms vxlan->age_timer whenever the requested ageing interval differs from the configured one: if (conf.age_interval != vxlan->cfg.age_interval) mod_timer(&vxlan->age_timer, jiffies); There is no netif_running() test, so the timer is armed even on a device that was never brought up. The only synchronous cancel in the driver is the timer_delete_sync() in vxlan_stop(), which is .ndo_stop. netif_close_many() drops devices without IFF_UP before __dev_close_many() runs, so that cancel is skipped for such a device. vxlan_setup() sets dev->needs_free_netdev = true and age_timer is a member of struct vxlan_dev, so free_netdev() releases the allocation the timer lives in while it is still queued on a timer_base. expire_timers() unlinks the entry before it loads timer->function, so the timer core writes through the freed object's list pointers: BUG: KASAN: slab-use-after-free in __run_timers+0x208/0x654 Write of size 8 at addr ffff00001adace68 by task true/192 __asan_store8+0x84/0xac __run_timers+0x208/0x654 run_timer_softirq+0x154/0x18c Allocated by task 189: alloc_netdev_mqs+0x64/0x720 rtnl_create_link+0x4ac/0x520 rtnl_newlink+0x758/0xd00 Freed by task 191: netdev_release+0x40/0x58 netdev_run_todo+0x4a4/0x8c0 rtnl_dellink+0x200/0x4e8 The rtnl operations involved are netns-scoped, so an unprivileged user can perform them in a new user and network namespace. Arming the timer on a down device never had an effect: vxlan_cleanup() returns early on !netif_running(), and vxlan_open() arms the timer for any non-zero interval once the device is brought up. Add the missing test. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com> | ||||
| CVE-2026-74603 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: ptp: ocp: Fix board ID over-read The EEPROM board ID is a fixed 13-byte field and is not guaranteed to contain a NUL terminator. Passing it directly to devlink_info_version_fixed_put() treats it as a C string and may read beyond the field. Format at most OCP_BOARD_ID_LEN bytes into the existing local buffer before reporting the ID. Use a precision limit because the snprintf() output size alone does not bound the source string scan. | ||||
| CVE-2026-56702 | 2 Adminer, Vrana | 2 Adminer, Adminer | 2026-08-25 | 8.8 High |
| Adminer versions before 5.4.3 contain an unrestricted file upload vulnerability in the AdminerFileUpload plugin that allows authenticated users to upload PHP files by exploiting a permissive default extension allowlist. Attackers can upload PHP webshells to columns ending in _path and execute arbitrary code as the web-server user when uploadPath is web-served. | ||||
| CVE-2026-56703 | 2 Adminer, Vrana | 2 Adminer, Adminer | 2026-08-25 | 7.2 High |
| Adminer before 5.4.3 contains a remote code execution vulnerability in SQLite query handling where VACUUM INTO is not blocked despite ATTACH restrictions. Authenticated attackers can execute VACUUM INTO to write PHP code to arbitrary file paths and execute commands on the server. | ||||
| CVE-2026-78477 | 2 Mvpthemes, Wordpress | 2 Jawn, Wordpress | 2026-08-25 | 9.8 Critical |
| The Jawn theme for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 1.4.2. This makes it possible for unauthenticated attackers to elevate their privileges to that of an administrator. | ||||
| CVE-2026-66109 | 2026-08-25 | N/A | ||
| A missing authorization vulnerability exists in SKYSEA Client View and SKYMEC IT Manager. If this vulnerability is exploited, an attacker who can log in to the Windows system on which the affected product is installed may execute arbitrary code with SYSTEM privilege. | ||||
| CVE-2026-74676 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: vt: add permission check for KDSKBMETA ioctl KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all other keyboard setter ioctls in vt_k_ioctl() enforce, allowing a process to change meta mode on a non-controlling console without authorization. | ||||
| CVE-2025-41741 | 2026-08-25 | N/A | ||
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-74730 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: NFS: Pin the 'struct nfs_server' during a FREE_STATEID call Dan Aloni reports that he was able to hit a use-after-free bug if a FREE_STATEID operation gets delayed for whatever reason. Fix this by bumping the refcount of the 'struct nfs_server' object for the duration of the FREE_STATEID so it doesn't get cleaned up from underneath us while operations are still in flight. | ||||
| CVE-2026-74717 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fw_tracer, return NULL on create error Tracer creation can fail by returning either NULL or ERR_PTR. The return value is stored without a check on the device, and users treat ERR_PTR and NULL the same way. This also causes a crash in the core dump logic, which is missing the ERR_PTR check and ends up dereferencing it, as shown in the trace below. Switch tracer creation to return NULL on failure only, so callers only need a single NULL check. Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: mlx5_ib ib_uverbs ib_core ipv6 mlx5_core CPU: 1 UID: 0 PID: 12 Comm: kworker/u16:0 Not tainted 6.19.7 #1 PREEMPT(none) Workqueue: mlx5_health0001:01:00.0 mlx5_fw_reporter_err_work [mlx5_core] pstate: a3400009 (NzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] lr : mlx5_fw_tracer_trigger_core_dump_general+0x40/0xe0 [mlx5_core] sp : ffff800081cf3c40 x29: ffff800081cf3c90 x28: 0000000000000000 x27: 0000000000000000 x26: ffff000080018828 x25: 0000000000000000 x24: ffff000080304a05 x23: ffff800081cf3d80 x22: ffff0000847e01a0 x21: 0000000000000000 x20: ffff0000847e01a0 x19: ffffffffffffffa1 x18: ffff80008310bbf0 x17: ffff800080119650 x16: ffff80008010df54 x15: ffff80008010d4ac x14: ffff800079c202e4 x13: ffff80008002fe60 x12: ffff800080119650 x11: ffff80008010df54 x10: ffff80008010d4ac x9 : ffff800079c203d8 x8 : ffff800081cf3c88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000008 x3 : 0000000000000030 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 00000000c5c4000e Call trace: mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] (P) mlx5_fw_reporter_dump+0x30/0x2e0 [mlx5_core] devlink_health_do_dump+0x9c/0x160 devlink_health_report+0x1c0/0x288 mlx5_fw_reporter_err_work+0xac/0xc0 [mlx5_core] process_one_work+0x15c/0x3d8 worker_thread+0x18c/0x320 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: b9400000 5ac00800 7a401800 540003ca (3940a260) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x000000,00078031,75fce5a1,35fffe67 Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception ]--- | ||||
| CVE-2026-74714 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch() reqsk_queue_hash_req() publishes a TCP_NEW_SYN_RECV request_sock onto the ehash chain, drops the bucket lock, and only afterwards sets rsk_refcnt to 3. Lockless readers such as __inet_lookup_established() handle this with refcount_inc_not_zero(), but bpf_iter_tcp_established_batch() uses plain sock_hold() while holding the bucket lock, on the assumption that the lock guarantees sk_refcnt > 0. That assumption does not hold for request_sock: CPU 0 CPU 1 ----- ----- tcp_conn_request() reqsk_queue_hash_req() inet_ehash_insert(req) spin_lock(bucket) __sk_nulls_add_node_rcu(req) // rsk_refcnt == 0 spin_unlock(bucket) bpf_iter_tcp_established_batch() spin_lock(bucket) sock_hold(req) <-- addition on 0 spin_unlock(bucket) refcount_set(&req->rsk_refcnt, 3) // clobbers saturated value which surfaces as: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x48/0x90, CPU#1 Call Trace: bpf_iter_tcp_established_batch+0x14e/0x170 bpf_iter_tcp_batch+0x53/0x200 bpf_iter_tcp_seq_next+0x27/0x70 bpf_seq_read+0x107/0x410 vfs_read+0xb9/0x380 The iterator's stolen reference is lost when the publishing CPU's refcount_set() overwrites the count, leaving the socket one reference short. When the last legitimate owner drops its reference the reqsk is freed while still reachable, leading to use-after-free. This reproduces in seconds with tcp_syncookies=0, a handful of threads doing connect()/close() to a local listener while others read an iter/tcp link in a tight loop. Use refcount_inc_not_zero() and skip the socket on failure. A skipped socket is still part of the bucket, so keep counting it in expected. The reallocations are sized from expected, and a request sock whose refcount gets published while the lock is held across the last realloc must already have room. A skipped socket is counted in expected but never batched, so end_sk can be short of expected on a batch that is actually complete. Decide completeness by whether the walk left any socket behind instead. The WARN after the locked realloc checks the same, replacing an end_sk == expected check that could not hold on that path since commit cdec67a489d4 ("bpf: tcp: Make sure iter->batch always contains a full bucket snapshot"). If every matching socket in a bucket is mid-init (refcount 0), end_sk stays 0. Advance to the next bucket rather than returning a batch entry that was never filled this round. | ||||
| CVE-2026-74712 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 9.3 Critical |
| In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix buffer length in create_direct_keys() We have seen in our CI the following KASAN message: BUG: KASAN: slab-out-of-bounds in cmd_exec+0x550/0xca0 [mlx5_core] Read of size 272 at addr 0000000176795020 by task qemu-system-s39/82764 [...] [<000011388ab3a7a0>] cmd_exec+0x550/0xca0 [mlx5_core] [<000011388ab3b61c>] mlx5_cmd_exec_cb+0x25c/0x4f0 [mlx5_core] [<000011388b21e82e>] mlx5_vdpa_exec_async_cmds+0x22e/0x5e0 [mlx5_vdpa] [<000011388b21fd44>] create_direct_keys+0x954/0xef0 [mlx5_vdpa] [...] The buggy address is located 4128 bytes inside of allocated 4384-byte region [0000000176794000, 0000000176795120) So in essence we read 16 bytes beyond 4384-byte allocation. create_direct_keys calculates the pointer and length for in and out buffers. The size calculation for in includes the entire structure size (out + in + mtt[]) but the pointer passed to cmd_exec points only to the 'in' field, skipping the 'out' field. This causes mlx5_copy_to_msg() to read beyond the allocated buffer by sizeof(out) bytes when copying command data. Properly calculate the input size to match the pointer and allocation size. | ||||
| CVE-2026-74700 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers Another challenge with unlocked filters. There is a short window in tc_new_tfilter where a tcf_proto can be found and briefly referenced by a totally unrelated, unlocked classifier's request and cause a race. Feng created a poc which created this race with two threads, one creating a u32 filter and other a flower filter in the same chain/prio: 1. Both threads enter tc_new_tfilter, both find the chain empty, both drop filter_chain_lock 2. u32 finishes tcf_proto_create("u32") first, calls tcf_chain_tp_insert_unique() -> inserts u32_tp into the chain 3. flower finishes tcf_proto_create("flower") later, calls tcf_chain_tp_insert_unique() -> tcf_chain_tp_find() now sees u32_tp already there, takes a reference on it, destroys flower's own tp_new and returns u32_tp to the caller. Flower then hits the kind mismatch check (because it requested for kind "flower" but tp->ops->kind is "u32") and goes through the errout path which calls tcf_proto_put() on u32_tp. If the u32 thread has already gone through its own errout (its change() call failed on the PoC's empty options) and dropped its create and insert refs, flower's put is the last one and drops u32_tp's refcnt to zero. At this point tp->ops->destroy() runs in a context that never took rtnl_lock. When that happens, it might cause a UAF like the following (illustrated by the PoC): [ +0.000710] BUG: KASAN: slab-use-after-free in u32_init (net/sched/cls_u32.c:393) [ +0.000281] Read of size 8 at addr ffff888120022f00 by task poc_feng_xue/524 Call Trace: u32_init (net/sched/cls_u32.c:393) tc_new_tfilter (net/sched/cls_api.c:2378) Allocated by task 526: u32_init (net/sched/cls_u32.c:378) tc_new_tfilter (net/sched/cls_api.c:2378) Freed by task 522: kfree u32_destroy (net/sched/cls_u32.c:662) tcf_proto_destroy (net/sched/cls_api.c:446) tcf_proto_put (net/sched/cls_api.c:459) tc_new_tfilter (net/sched/cls_api.c:2459) Fix this by having tcf_proto_destroy() take rtnl_lock around tp->ops->destroy() for locked classifiers whenever rtnl is not held. To explain why I used a temp variable "not_lockless" I'd like to point to a semi-related note on rtnl_held vs TCF_PROTO_OPS_DOIT_UNLOCKED (adding here for future cleanup if deemed necessary): The rtnl_held parameter and the TCF_PROTO_OPS_DOIT_UNLOCKED flag are redundant sources of truth for whether rtnl_lock is held. Among the nine classifier destroy(..rtnl_held..) callbacks, only flower consults the rtnl_held parameter which it propagates to tc_setup_cb_destroy() and tc_setup_cb_call(). The other eight (u32, flow, bpf, cgroup, route, basic, fw, mall) ignore it entirely;-> those that call tc_setup_cb_destroy() (u32, bpf, mall) hardcode true always instead of forwarding the parameter. A future cleanup should remove the rtnl_held parameter from the destroy callback signature entirely and have callers rely solely on their knowledge whether they are running in an unlocked context. | ||||
| CVE-2026-74695 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_flow_table: drop existing skb dst before skb_dst_set_noref() Incoming skbs passing through netfilter flowtable offload hooks (or XFRM offload path) might already carry a ref-counted dst_entry assigned during earlier RX or routing steps. Calling skb_dst_set_noref() when skb already holds a ref-counted dst overwrites skb->_skb_refdst, leaking the previous dst_entry reference count and triggering a DEBUG_NET_WARN_ON_ONCE assertion in skb_dst_check_unset(): WARNING: at skb_dst_check_unset include/linux/skbuff.h:1170 WARNING: at skb_dst_set_noref include/linux/skbuff.h:1234 WARNING: at nf_flow_offload_ip_hook+0xf6c/0x2b60 net/netfilter/nf_flow_table_ip.c:864 Drop any existing dst_entry reference with skb_dst_drop(skb) before setting the non-referenced flowtable destination. | ||||
| CVE-2026-74687 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: watchdog: at91sam9_wdt: prevent timer rearm during teardown at91_ping() rearms the watchdog timer from its callback. timer_delete() neither waits for a running callback nor prevents it from rearming the timer, so probe failure or driver removal can leave the timer accessing the devm-allocated at91wdt after it has been freed. Use timer_shutdown_sync() on both teardown paths. It waits for a running callback and rejects any attempt by the callback to rearm the timer. | ||||
| CVE-2026-74669 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: ipvs: clear IPv4 options after rebasing tunnel ICMP errors ip_vs_in_icmp() rebases an skb from the outer ICMP packet to the quoted original request before passing it to icmp_send(). However, IPCB(skb)->opt still describes the outer IPv4 header. A timestamp option in the outer header can therefore leave an offset that points into the quoted transport header after the rebase. __ip_options_echo() treats a byte at that stale location as the option length and copies it into the fixed-size option storage on the __icmp_send() stack, causing a stack out-of-bounds write. Clear the stale option metadata after resetting the network header. Keep the remaining control block fields, including the ingress interface used by the ICMP response path. | ||||
| CVE-2026-74668 | 1 Linux | 1 Linux Kernel | 2026-08-25 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in TX_RING send path tpacket_snd() reads dev->hard_header_len independently for skb allocation and header construction in tpacket_fill_skb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hard_header_len negative. Snapshot hard_header_len once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacket_fill_skb(). The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here. | ||||