Total
29775 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-38721 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-01-09 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: fix refcount leak on table dump There is a reference count leak in ctnetlink_dump_table(): if (res < 0) { nf_conntrack_get(&ct->ct_general); // HERE cb->args[1] = (unsigned long)ct; ... While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone. This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0. This will then block the netns dismantle (or conntrack rmmod) as nf_conntrack_cleanup_net_list() will wait forever. This can be reproduced by running conntrack_resize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nf_conntrack_cleanup_net_list. One fix would to change this to: if (res < 0) { if (ct != last) nf_conntrack_get(&ct->ct_general); But this reference counting isn't needed in the first place. We can just store a cookie value instead. A followup patch will do the same for ctnetlink_exp_dump_table, it looks to me as if this has the same problem and like ctnetlink_dump_table, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well. | |||||
| CVE-2025-14072 | 1 Ninjaforms | 1 Ninja Forms | 2026-01-09 | N/A | 5.3 MEDIUM |
| The Ninja Forms WordPress plugin before 3.13.3 allows unauthenticated attackers to generate valid access tokens via the REST API which can then be used to read form submissions. | |||||
| CVE-2024-49417 | 1 Samsung | 1 Smart Touch Call | 2026-01-09 | N/A | 2.0 LOW |
| Use of implicit intent for sensitive communication in Smart Touch Call prior to 1.0.0.8 allows local attackers to launch privileged activities. User interaction is required for triggering this vulnerability. | |||||
| CVE-2024-34670 | 1 Samsung | 1 Sound Assistant | 2026-01-08 | N/A | 4.0 MEDIUM |
| Use of implicit intent for sensitive communication in Sound Assistant prior to version 6.1.0.9 allows local attackers to get sensitive information. | |||||
| CVE-2023-2003 | 1 Unitronics | 2 Vision1210, Vision1210 Firmware | 2026-01-08 | N/A | 9.1 CRITICAL |
| Embedded malicious code vulnerability in Vision1210, in the build 5 of operating system version 4.3, which could allow a remote attacker to store base64-encoded malicious code in the device's data tables via the PCOM protocol, which can then be retrieved by a client and executed on the device. | |||||
| CVE-2025-58488 | 1 Samsung | 1 Smart Touch Call | 2026-01-08 | N/A | 4.5 MEDIUM |
| Improper verification of source of a communication channel in SmartTouchCall prior to version 1.0.1.1 allows remote attackers to access sensitive information. User interaction is required for triggering this vulnerability. | |||||
| CVE-2024-20872 | 1 Samsung | 1 Android | 2026-01-07 | N/A | 6.2 MEDIUM |
| Improper handling of insufficient privileges vulnerability in TalkbackSE prior to version Android 14 allows local attackers to modify setting value of TalkbackSE. | |||||
| CVE-2025-38542 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-01-07 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: appletalk: Fix device refcount leak in atrtr_create() When updating an existing route entry in atrtr_create(), the old device reference was not being released before assigning the new device, leading to a device refcount leak. Fix this by calling dev_put() to release the old device reference before holding the new one. | |||||
| CVE-2025-38639 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-01-07 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_nfacct: don't assume acct name is null-terminated BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721 Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851 [..] string+0x231/0x2b0 lib/vsprintf.c:721 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874 [..] nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523 nfnl_acct_find_get() handles non-null input, but the error printk relied on its presence. | |||||
| CVE-2025-14023 | 1 Linecorp | 1 Line | 2026-01-07 | N/A | 3.1 LOW |
| LINE client for iOS prior to 15.19 allows UI spoofing due to inconsistencies between the navigation state and the in-app browser's user interface, which could create confusion about the trust context of displayed pages or interactive elements under specific conditions. | |||||
| CVE-2025-15084 | 1 Youlai | 1 Youlai-mall | 2025-12-31 | 2.1 LOW | 3.1 LOW |
| A vulnerability was identified in youlaitech youlai-mall 1.0.0/2.0.0. The impacted element is the function orderService.payOrder of the file mall-oms/oms-boot/src/main/java/com/youlai/mall/oms/controller/app/OrderController.java of the component Order Payment Handler. The manipulation leads to improper access controls. The attack can be initiated remotely. The attack is considered to have high complexity. The exploitability is regarded as difficult. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way. | |||||
| CVE-2022-45475 | 1 Prasathmani | 1 Tiny File Manager | 2025-12-31 | N/A | 6.5 MEDIUM |
| Tiny File Manager version 2.4.8 allows an unauthenticated remote attacker to access the application's internal files. This is possible because the application is vulnerable to broken access control. | |||||
| CVE-2024-9180 | 2 Hashicorp, Openbao | 2 Vault, Openbao | 2025-12-31 | N/A | 7.2 HIGH |
| A privileged Vault operator with write permissions to the root namespace’s identity endpoint could escalate their own or another user’s privileges to Vault’s root policy. Fixed in Vault Community Edition 1.18.0 and Vault Enterprise 1.18.0, 1.17.7, 1.16.11, and 1.15.16. | |||||
| CVE-2024-23136 | 1 Autodesk | 9 Advance Steel, Autocad, Autocad Architecture and 6 more | 2025-12-31 | N/A | 7.8 HIGH |
| A maliciously crafted STP file in ASMKERN228A.dll when parsed through Autodesk applications can be used to dereference an untrusted pointer. This vulnerability, along with other vulnerabilities, could lead to code execution in the current process. | |||||
| CVE-2025-15121 | 1 Jeecg | 1 Jeecg Boot | 2025-12-30 | 2.2 LOW | 2.4 LOW |
| A vulnerability has been found in JeecgBoot up to 3.9.0. The affected element is the function getDeptRoleByUserId of the file /sys/sysDepartRole/getDeptRoleByUserId. Such manipulation of the argument departId leads to information disclosure. The vendor was contacted early about this disclosure but did not respond in any way. | |||||
| CVE-2024-22727 | 1 Teltonika | 10 Trb140, Trb140 Firmware, Trb141 and 7 more | 2025-12-23 | N/A | 8.3 HIGH |
| Teltonika TRB1-series devices with firmware before TRB1_R_00.07.05.2 allow attackers to exploit a firmware vulnerability via Ethernet LAN or USB. | |||||
| CVE-2025-36744 | 1 Solaredge | 2 Se3680h, Se3680h Firmware | 2025-12-23 | N/A | 2.4 LOW |
| SolarEdge SE3680H has unauthenticated disclosure of sensitive information during the bootloader loop. While the device repeatedly initializes and waits for boot instructions, the bootloader emits diagnostic output this behavior can leak operating system information. | |||||
| CVE-2025-36743 | 1 Solaredge | 2 Se3680h, Se3680h Firmware | 2025-12-23 | N/A | 6.8 MEDIUM |
| SolarEdge SE3680H has an exposed debug/test interface accessible to unauthenticated actors, allowing disclosure of system internals and execution of debug commands. | |||||
| CVE-2022-49979 | 1 Linux | 1 Linux Kernel | 2025-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: fix refcount bug in sk_psock_get (2) Syzkaller reports refcount bug as follows: ------------[ cut here ]------------ refcount_t: saturated; leaking memory. WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19 Modules linked in: CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0 <TASK> __refcount_add_not_zero include/linux/refcount.h:163 [inline] __refcount_inc_not_zero include/linux/refcount.h:227 [inline] refcount_inc_not_zero include/linux/refcount.h:245 [inline] sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909 __sys_shutdown_sock net/socket.c:2331 [inline] __sys_shutdown_sock net/socket.c:2325 [inline] __sys_shutdown+0xf1/0x1b0 net/socket.c:2343 __do_sys_shutdown net/socket.c:2351 [inline] __se_sys_shutdown net/socket.c:2349 [inline] __x64_sys_shutdown+0x50/0x70 net/socket.c:2349 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> During SMC fallback process in connect syscall, kernel will replaces TCP with SMC. In order to forward wakeup smc socket waitqueue after fallback, kernel will sets clcsk->sk_user_data to origin smc socket in smc_fback_replace_callbacks(). Later, in shutdown syscall, kernel will calls sk_psock_get(), which treats the clcsk->sk_user_data as psock type, triggering the refcnt warning. So, the root cause is that smc and psock, both will use sk_user_data field. So they will mismatch this field easily. This patch solves it by using another bit(defined as SK_USER_DATA_PSOCK) in PTRMASK, to mark whether sk_user_data points to a psock object or not. This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e ("net, sk_msg: Clear sk_user_data pointer on clone if tagged"). For there will possibly be more flags in the sk_user_data field, this patch also refactor sk_user_data flags code to be more generic to improve its maintainability. | |||||
| CVE-2025-38470 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-12-22 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime Assuming the "rx-vlan-filter" feature is enabled on a net device, the 8021q module will automatically add or remove VLAN 0 when the net device is put administratively up or down, respectively. There are a couple of problems with the above scheme. The first problem is a memory leak that can happen if the "rx-vlan-filter" feature is disabled while the device is running: # ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1 When the device is put administratively down the "rx-vlan-filter" feature is disabled, so the 8021q module will not remove VLAN 0 and the memory will be leaked [1]. Another problem that can happen is that the kernel can automatically delete VLAN 0 when the device is put administratively down despite not adding it when the device was put administratively up since during that time the "rx-vlan-filter" feature was disabled. null-ptr-unref or bug_on[2] will be triggered by unregister_vlan_dev() for refcount imbalance if toggling filtering during runtime: $ ip link add bond0 type bond mode 0 $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q $ ethtool -K bond0 rx-vlan-filter off $ ifconfig bond0 up $ ethtool -K bond0 rx-vlan-filter on $ ifconfig bond0 down $ ip link del vlan0 Root cause is as below: step1: add vlan0 for real_dev, such as bond, team. register_vlan_dev vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1 step2: disable vlan filter feature and enable real_dev step3: change filter from 0 to 1 vlan_device_event vlan_filter_push_vids ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0 step4: real_dev down vlan_device_event vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0 vlan_info_rcu_free //free vlan0 step5: delete vlan0 unregister_vlan_dev BUG_ON(!vlan_info); //vlan_info is null Fix both problems by noting in the VLAN info whether VLAN 0 was automatically added upon NETDEV_UP and based on that decide whether it should be deleted upon NETDEV_DOWN, regardless of the state of the "rx-vlan-filter" feature. [1] unreferenced object 0xffff8880068e3100 (size 256): comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): __kmalloc_cache_noprof+0x2b5/0x340 vlan_vid_add+0x434/0x940 vlan_device_event.cold+0x75/0xa8 notifier_call_chain+0xca/0x150 __dev_notify_flags+0xe3/0x250 rtnl_configure_link+0x193/0x260 rtnl_newlink_create+0x383/0x8e0 __rtnl_newlink+0x22c/0xa40 rtnl_newlink+0x627/0xb00 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 [2] kernel BUG at net/8021q/vlan.c:99! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1)) RSP: 0018:ffff88810badf310 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80 R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000 R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0 Call Trace: <TASK ---truncated--- | |||||