Total
34333 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-20976 | 1 Samsung | 1 Galaxy Store | 2026-01-15 | 7.8 High |
| Improper input validation in Galaxy Store prior to version 4.6.02 allows local attacker to execute arbitrary script. | ||||
| CVE-2026-20969 | 1 Samsung | 2 Android, Mobile Devices | 2026-01-15 | 5.5 Medium |
| Improper input validation in SecSettings prior to SMR Jan-2026 Release 1 allows local attacker to access file with system privilege. User interaction is required for triggering this vulnerability. | ||||
| CVE-2026-20970 | 1 Samsung | 3 Android, Mobile, Mobile Devices | 2026-01-15 | 7.8 High |
| Improper access control in SLocation prior to SMR Jan-2026 Release 1 allows local attackers to execute the privileged APIs. | ||||
| CVE-2025-68959 | 1 Huawei | 2 Emui, Harmonyos | 2026-01-15 | 6.2 Medium |
| Permission verification bypass vulnerability in the media library module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2025-68967 | 1 Huawei | 1 Harmonyos | 2026-01-15 | 5.7 Medium |
| Vulnerability of improper permission control in the print module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2025-68966 | 1 Huawei | 1 Harmonyos | 2026-01-15 | 5.1 Medium |
| Permission control vulnerability in the Notepad module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2025-68965 | 1 Huawei | 1 Harmonyos | 2026-01-15 | 4.7 Medium |
| Permission control vulnerability in the Notepad module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2025-68964 | 1 Huawei | 1 Harmonyos | 2026-01-15 | 6.2 Medium |
| Data verification vulnerability in the HiView module. Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2025-68963 | 1 Huawei | 2 Emui, Harmonyos | 2026-01-15 | 5.7 Medium |
| Man-in-the-middle attack vulnerability in the Clone module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2025-68970 | 1 Huawei | 2 Emui, Harmonyos | 2026-01-15 | 6.1 Medium |
| Permission verification bypass vulnerability in the media library module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2025-0358 | 1 Axis | 1 Axis Os | 2026-01-15 | 8.8 High |
| During an annual penetration test conducted on behalf of Axis Communication, Truesec discovered a flaw in the VAPIX Device Configuration framework that allowed a privilege escalation, enabling a lower-privileged user to gain administrator privileges. | ||||
| CVE-2025-43882 | 1 Dell | 33 Latitude 3330, Latitude 3420, Latitude 3440 and 30 more | 2026-01-15 | 7.8 High |
| Dell ThinOS 10, versions prior to 2508_10.0127, contains an Unverified Ownership vulnerability. A local low-privileged attacker could potentially exploit this vulnerability leading to Unauthorized Access. | ||||
| CVE-2025-11192 | 2 Extreme Networks, Extremenetworks | 2 Fabric Engine, Fabric Engine \(voss\) | 2026-01-15 | 8.6 High |
| A vulnerability in Extreme Networks’ Fabric Engine (VOSS) before 9.3 was discovered. When SD-WAN AutoSense is enabled on a port, it may automatically configure fabric connectivity without validating ISIS authentication settings. The SD-WAN AutoSense implementation may be exploited by malicious actors by allowing unauthorized access to network fabric and configuration data. | ||||
| CVE-2025-2529 | 1 Ibm | 1 Terracotta | 2026-01-14 | 2.9 Low |
| Applications using affected versions of Ehcache 3.x can experience degraded cache-write performance if the application using Ehcache utilizes keys sourced from (malicious) external parties in an unfiltered/unsalted way. | ||||
| CVE-2025-64990 | 1 Teamviewer | 2 Dex, Digital Employee Experience | 2026-01-14 | 6.8 Medium |
| A command injection vulnerability was discovered in TeamViewer DEX (former 1E DEX), specifically within the 1E-Explorer-TachyonCore-LogoffUser instruction prior V21.1. Improper input validation, allowing authenticated attackers with Actioner privileges to inject arbitrary commands. Exploitation enables remote execution of elevated commands on devices connected to the platform. | ||||
| CVE-2025-64989 | 1 Teamviewer | 2 Dex, Digital Employee Experience | 2026-01-14 | 7.2 High |
| A command injection vulnerability was discovered in TeamViewer DEX (former 1E DEX), specifically within the 1E-Explorer-TachyonCore-FindFileBySizeAndHash instruction prior V21.1. Improper input validation, allowing authenticated attackers with Actioner privileges to inject arbitrary commands. Exploitation enables remote execution of elevated commands on devices connected to the platform. | ||||
| CVE-2025-39900 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net_sched: gen_estimator: fix est_timer() vs CONFIG_PREEMPT_RT=y syzbot reported a WARNING in est_timer() [1] Problem here is that with CONFIG_PREEMPT_RT=y, timer callbacks can be preempted. Adopt preempt_disable_nested()/preempt_enable_nested() to fix this. [1] WARNING: CPU: 0 PID: 16 at ./include/linux/seqlock.h:221 __seqprop_assert include/linux/seqlock.h:221 [inline] WARNING: CPU: 0 PID: 16 at ./include/linux/seqlock.h:221 est_timer+0x6dc/0x9f0 net/core/gen_estimator.c:93 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:__seqprop_assert include/linux/seqlock.h:221 [inline] RIP: 0010:est_timer+0x6dc/0x9f0 net/core/gen_estimator.c:93 Call Trace: <TASK> call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22c/0x710 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1043 smpboot_thread_fn+0x53f/0xa60 kernel/smpboot.c:160 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> | ||||
| CVE-2025-39899 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE With CONFIG_HIGHPTE on 32-bit ARM, move_pages_pte() maps PTE pages using kmap_local_page(), which requires unmapping in Last-In-First-Out order. The current code maps dst_pte first, then src_pte, but unmaps them in the same order (dst_pte, src_pte), violating the LIFO requirement. This causes the warning in kunmap_local_indexed(): WARNING: CPU: 0 PID: 604 at mm/highmem.c:622 kunmap_local_indexed+0x178/0x17c addr \!= __fix_to_virt(FIX_KMAP_BEGIN + idx) Fix this by reversing the unmap order to respect LIFO ordering. This issue follows the same pattern as similar fixes: - commit eca6828403b8 ("crypto: skcipher - fix mismatch between mapping and unmapping order") - commit 8cf57c6df818 ("nilfs2: eliminate staggered calls to kunmap in nilfs_rename") Both of which addressed the same fundamental requirement that kmap_local operations must follow LIFO ordering. | ||||
| CVE-2025-39886 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init() Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example: ... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ... The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event. We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc. As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there. Depends on mm patch "memcg: skip cgroup_file_notify if spinning is not allowed": https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/ v0 approach s/bpf_map_kmalloc_node/bpf_mem_alloc/ https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/ v1 approach: https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/ | ||||
| CVE-2025-39874 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: macsec: sync features on RTM_NEWLINK Syzkaller managed to lock the lower device via ETHTOOL_SFEATURES: netdev_lock include/linux/netdevice.h:2761 [inline] netdev_lock_ops include/net/netdev_lock.h:42 [inline] netdev_sync_lower_features net/core/dev.c:10649 [inline] __netdev_update_features+0xcb1/0x1be0 net/core/dev.c:10819 netdev_update_features+0x6d/0xe0 net/core/dev.c:10876 macsec_notify+0x2f5/0x660 drivers/net/macsec.c:4533 notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85 call_netdevice_notifiers_extack net/core/dev.c:2267 [inline] call_netdevice_notifiers net/core/dev.c:2281 [inline] netdev_features_change+0x85/0xc0 net/core/dev.c:1570 __dev_ethtool net/ethtool/ioctl.c:3469 [inline] dev_ethtool+0x1536/0x19b0 net/ethtool/ioctl.c:3502 dev_ioctl+0x392/0x1150 net/core/dev_ioctl.c:759 It happens because lower features are out of sync with the upper: __dev_ethtool (real_dev) netdev_lock_ops(real_dev) ETHTOOL_SFEATURES __netdev_features_change netdev_sync_upper_features disable LRO on the lower if (old_features != dev->features) netdev_features_change fires NETDEV_FEAT_CHANGE macsec_notify NETDEV_FEAT_CHANGE netdev_update_features (for each macsec dev) netdev_sync_lower_features if (upper_features != lower_features) netdev_lock_ops(lower) # lower == real_dev stuck ... netdev_unlock_ops(real_dev) Per commit af5f54b0ef9e ("net: Lock lower level devices when updating features"), we elide the lock/unlock when the upper and lower features are synced. Makes sure the lower (real_dev) has proper features after the macsec link has been created. This makes sure we never hit the situation where we need to sync upper flags to the lower. | ||||