Export limit exceeded: 110504 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (110504 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-42035 | 1 Huawei | 2 Emui, Harmonyos | 2025-09-18 | 8.4 High |
| Permission control vulnerability in the App Multiplier module Impact:Successful exploitation of this vulnerability may affect functionality and confidentiality. | ||||
| CVE-2024-36906 | 1 Linux | 1 Linux Kernel | 2025-09-17 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ARM: 9381/1: kasan: clear stale stack poison We found below OOB crash: [ 33.452494] ================================================================== [ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0 [ 33.455515] [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1 [ 33.456880] Hardware name: Generic DT based system [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c [ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4 [ 33.459863] print_report from kasan_report+0x9c/0x148 [ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0 [ 33.461424] kasan_check_range from memset+0x20/0x3c [ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354 [ 33.465029] do_idle from cpu_startup_entry+0x20/0x24 [ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4 [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18 [ 33.467397] [ 33.467644] The buggy address belongs to stack of task swapper/0/0 [ 33.468493] and is located at offset 112 in frame: [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec [ 33.469917] [ 33.470165] This frame has 2 objects: [ 33.470696] [32, 76) 'global_zone_diff' [ 33.470729] [112, 276) 'global_node_diff' [ 33.471294] [ 33.472095] The buggy address belongs to the physical page: [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03 [ 33.473944] flags: 0x1000(reserved|zone=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001 [ 33.475656] raw: 00000000 [ 33.476050] page dumped because: kasan: bad access detected [ 33.476816] [ 33.477061] Memory state around the buggy address: [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] ================================================================== We find the root cause of this OOB is that arm does not clear stale stack poison in the case of cpuidle. This patch refer to arch/arm64/kernel/sleep.S to resolve this issue. From cited commit [1] that explain the problem Functions which the compiler has instrumented for KASAN place poison on the stack shadow upon entry and remove this poison prior to returning. In the case of cpuidle, CPUs exit the kernel a number of levels deep in C code. Any instrumented functions on this critical path will leave portions of the stack shadow poisoned. If CPUs lose context and return to the kernel via a cold path, we restore a prior context saved in __cpu_suspend_enter are forgotten, and we never remove the poison they placed in the stack shadow area by functions calls between this and the actual exit of the kernel. Thus, (depending on stackframe layout) subsequent calls to instrumented functions may hit this stale poison, resulting in (spurious) KASAN splats to the console. To avoid this, clear any stale poison from the idle thread for a CPU prior to bringing a CPU online. From cited commit [2] Extend to check for CONFIG_KASAN_STACK [1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison") [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK") | ||||
| CVE-2025-57392 | 1 Benimpos | 1 Benimpos | 2025-09-17 | 7.8 High |
| BenimPOS Masaustu 3.0.x is affected by insecure file permissions. The application installation directory grants Everyone and BUILTIN\Users groups FILE_ALL_ACCESS, allowing local users to replace or modify .exe and .dll files. This may lead to privilege escalation or arbitrary code execution upon launch by another user or elevated context. | ||||
| CVE-2024-38586 | 2 Linux, Redhat | 6 Linux Kernel, Enterprise Linux, Rhel Aus and 3 more | 2025-09-17 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: r8169: Fix possible ring buffer corruption on fragmented Tx packets. An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied. | ||||
| CVE-2024-38585 | 1 Linux | 1 Linux Kernel | 2025-09-17 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: tools/nolibc/stdlib: fix memory error in realloc() Pass user_p_len to memcpy() instead of heap->len to prevent realloc() from copying an extra sizeof(heap) bytes from beyond the allocated region. | ||||
| CVE-2024-36963 | 1 Linux | 1 Linux Kernel | 2025-09-17 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: tracefs: Reset permissions on remount if permissions are options There's an inconsistency with the way permissions are handled in tracefs. Because the permissions are generated when accessed, they default to the root inode's permission if they were never set by the user. If the user sets the permissions, then a flag is set and the permissions are saved via the inode (for tracefs files) or an internal attribute field (for eventfs). But if a remount happens that specify the permissions, all the files that were not changed by the user gets updated, but the ones that were are not. If the user were to remount the file system with a given permission, then all files and directories within that file system should be updated. This can cause security issues if a file's permission was updated but the admin forgot about it. They could incorrectly think that remounting with permissions set would update all files, but miss some. For example: # cd /sys/kernel/tracing # chgrp 1002 current_tracer # ls -l [..] -rw-r----- 1 root root 0 May 1 21:25 buffer_size_kb -rw-r----- 1 root root 0 May 1 21:25 buffer_subbuf_size_kb -r--r----- 1 root root 0 May 1 21:25 buffer_total_size_kb -rw-r----- 1 root lkp 0 May 1 21:25 current_tracer -rw-r----- 1 root root 0 May 1 21:25 dynamic_events -r--r----- 1 root root 0 May 1 21:25 dyn_ftrace_total_info -r--r----- 1 root root 0 May 1 21:25 enabled_functions Where current_tracer now has group "lkp". # mount -o remount,gid=1001 . # ls -l -rw-r----- 1 root tracing 0 May 1 21:25 buffer_size_kb -rw-r----- 1 root tracing 0 May 1 21:25 buffer_subbuf_size_kb -r--r----- 1 root tracing 0 May 1 21:25 buffer_total_size_kb -rw-r----- 1 root lkp 0 May 1 21:25 current_tracer -rw-r----- 1 root tracing 0 May 1 21:25 dynamic_events -r--r----- 1 root tracing 0 May 1 21:25 dyn_ftrace_total_info -r--r----- 1 root tracing 0 May 1 21:25 enabled_functions Everything changed but the "current_tracer". Add a new link list that keeps track of all the tracefs_inodes which has the permission flags that tell if the file/dir should use the root inode's permission or not. Then on remount, clear all the flags so that the default behavior of using the root inode's permission is done for all files and directories. | ||||
| CVE-2025-58750 | 1 Rathena | 1 Rathena | 2025-09-17 | 8.2 High |
| rAthena is an open-source cross-platform massively multiplayer online role playing game (MMORPG) server. Versions prior to commit 0cc348b are missing a bound check in `chclif_parse_moveCharSlot` that can result in reading and writing out of bounds using input from the user. The problem has been fixed in commit 0cc348b. | ||||
| CVE-2025-58362 | 1 Hono | 1 Hono | 2025-09-17 | 7.5 High |
| Hono is a Web application framework that provides support for any JavaScript runtime. Versions 4.8.0 through 4.9.5 contain a flaw in the getPath utility function which could allow path confusion and potential bypass of proxy-level ACLs (e.g. Nginx location blocks). The original implementation relied on fixed character offsets when parsing request URLs. Under certain malformed absolute-form Request-URIs, this could lead to incorrect path extraction depending on the application and environment. If proxy ACLs are used to protect sensitive endpoints such as /admin, this flaw could have allowed unauthorized access. The confidentiality impact depends on what data is exposed: if sensitive administrative data is exposed, the impact may be high, otherwise it may be moderate. This issue is fixed in version 4.9.6. | ||||
| CVE-2024-32652 | 1 Hono | 1 Node-server | 2025-09-17 | 7.5 High |
| The adapter @hono/node-server allows you to run your Hono application on Node.js. Prior to 1.10.1, the application hangs when receiving a Host header with a value that `@hono/node-server` can't handle well. Invalid values are those that cannot be parsed by the `URL` as a hostname such as an empty string, slashes `/`, and other strings. The version 1.10.1 includes the fix for this issue. | ||||
| CVE-2025-56404 | 1 Mariadb | 3 Mariadb, Mcp, Model Context Protocol | 2025-09-17 | 7.5 High |
| An issue was discovered in MariaDB MCP 0.1.0 allowing attackers to gain sensitive information via the SSE service as the SSE service lacks user validation. | ||||
| CVE-2025-56405 | 1 Litmus | 1 Mcp Server | 2025-09-17 | 7.5 High |
| An issue was discovered in litmusautomation litmus-mcp-server thru 0.0.1 allowing unauthorized attackers to control the target's MCP service through the SSE protocol. | ||||
| CVE-2025-57078 | 1 Tenda | 2 G3, G3 Firmware | 2025-09-17 | 7.5 High |
| Tenda G3 v3.0br_V15.11.0.17 was discovered to contain a stack overflow in the pppoeServerWhiteMacIndex parameter in the formModifyPppAuthWhiteMac function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. | ||||
| CVE-2025-57086 | 1 Tenda | 2 W30e, W30e Firmware | 2025-09-17 | 7.5 High |
| Tenda W30E V16.01.0.19 (5037) was discovered to contain a stack overflow in the String parameter in the formDeleteMeshNode function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. | ||||
| CVE-2025-57060 | 1 Tenda | 2 G3, G3 Firmware | 2025-09-17 | 7.5 High |
| Tenda G3 v3.0br_V15.11.0.17 was discovered to contain a stack overflow in the rules parameter in the dns_forward_rule_store function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. | ||||
| CVE-2025-5806 | 1 Jenkins | 1 Gatling | 2025-09-17 | 8 High |
| Jenkins Gatling Plugin 136.vb_9009b_3d33a_e serves Gatling reports in a manner that bypasses the Content-Security-Policy protection introduced in Jenkins 1.641 and 1.625, resulting in a cross-site scripting (XSS) vulnerability exploitable by users able to change report content. | ||||
| CVE-2025-30279 | 1 Qnap | 1 File Station | 2025-09-17 | 8.8 High |
| An improper certificate validation vulnerability has been reported to affect File Station 5. If a remote attacker gains a user account, they can then exploit the vulnerability to compromise the security of the system. We have already fixed the vulnerability in the following version: File Station 5 5.5.6.4847 and later | ||||
| CVE-2025-33031 | 1 Qnap | 1 File Station | 2025-09-17 | 8.8 High |
| An improper certificate validation vulnerability has been reported to affect File Station 5. If a remote attacker gains a user account, they can then exploit the vulnerability to compromise the security of the system. We have already fixed the vulnerability in the following version: File Station 5 5.5.6.4847 and later | ||||
| CVE-2025-43866 | 1 Vantage6 | 1 Vantage6 | 2025-09-17 | 7.5 High |
| vantage6 is an open-source infrastructure for privacy preserving analysis. The JWT secret key in the vantage6 server is auto-generated unless defined by the user. The auto-generated key is a UUID1, which is not cryptographically secure as it is predictable to some extent. This vulnerability is fixed in 4.11.0. | ||||
| CVE-2022-48757 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Rhel Eus | 2025-09-17 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: net: fix information leakage in /proc/net/ptype In one net namespace, after creating a packet socket without binding it to a device, users in other net namespaces can observe the new `packet_type` added by this packet socket by reading `/proc/net/ptype` file. This is minor information leakage as packet socket is namespace aware. Add a net pointer in `packet_type` to keep the net namespace of of corresponding packet socket. In `ptype_seq_show`, this net pointer must be checked when it is not NULL. | ||||
| CVE-2022-48714 | 1 Linux | 1 Linux Kernel | 2025-09-17 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Use VM_MAP instead of VM_ALLOC for ringbuf After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages after mapping"), non-VM_ALLOC mappings will be marked as accessible in __get_vm_area_node() when KASAN is enabled. But now the flag for ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access after vmap() returns. Because the ringbuf area is created by mapping allocated pages, so use VM_MAP instead. After the change, info in /proc/vmallocinfo also changes from [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user to [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user | ||||