Export limit exceeded: 390759 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (50092 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2021-25487 | 1 Samsung | 1 Android | 2025-10-30 | 7.3 High |
| Lack of boundary checking of a buffer in set_skb_priv() of modem interface driver prior to SMR Oct-2021 Release 1 allows OOB read and it results in arbitrary code execution by dereference of invalid function pointer. | ||||
| CVE-2021-25489 | 1 Samsung | 1 Android | 2025-10-30 | 3.3 Low |
| Assuming radio permission is gained, missing input validation in modem interface driver prior to SMR Oct-2021 Release 1 results in format string bug leading to kernel panic. | ||||
| CVE-2024-30155 | 1 Hcltech | 1 Hcl Sx | 2025-10-30 | 5.5 Medium |
| HCL SX does not set the secure attribute on authorization tokens or session cookies. Attackers may potentially be able to obtain access to the cookie values via a Cross-Site-Forgery-Request (CSRF). | ||||
| CVE-2025-21840 | 1 Linux | 1 Linux Kernel | 2025-10-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: thermal/netlink: Prevent userspace segmentation fault by adjusting UAPI header The intel-lpmd tool [1], which uses the THERMAL_GENL_ATTR_CPU_CAPABILITY attribute to receive HFI events from kernel space, encounters a segmentation fault after commit 1773572863c4 ("thermal: netlink: Add the commands and the events for the thresholds"). The issue arises because the THERMAL_GENL_ATTR_CPU_CAPABILITY raw value was changed while intel_lpmd still uses the old value. Although intel_lpmd can be updated to check the THERMAL_GENL_VERSION and use the appropriate THERMAL_GENL_ATTR_CPU_CAPABILITY value, the commit itself is questionable. The commit introduced a new element in the middle of enum thermal_genl_attr, which affects many existing attributes and introduces potential risks and unnecessary maintenance burdens for userspace thermal netlink event users. Solve the issue by moving the newly introduced THERMAL_GENL_ATTR_TZ_PREV_TEMP attribute to the end of the enum thermal_genl_attr. This ensures that all existing thermal generic netlink attributes remain unaffected. [ rjw: Subject edits ] | ||||
| CVE-2025-62493 | 2 Quickjs-ng, Quickjs Project | 2 Quickjs, Quickjs | 2025-10-29 | 6.5 Medium |
| A vulnerability exists in the QuickJS engine's BigInt string conversion logic (js_bigint_to_string1) due to an incorrect calculation of the required number of digits, which in turn leads to reading memory past the allocated BigInt structure. * The function determines the number of characters (n_digits) needed for the string representation by calculating: $$ \\ \text{n\_digits} = (\text{n\_bits} + \text{log2\_radix} - 1) / \text{log2\_radix}$$ $$$$This formula is off-by-one in certain edge cases when calculating the necessary memory limbs. For instance, a 127-bit BigInt using radix 32 (where $\text{log2\_radix}=5$) is calculated to need $\text{n\_digits}=26$. * The maximum number of bits actually stored is $\text{n\_bits}=127$, which requires only two 64-bit limbs ($\text{JS\_LIMB\_BITS}=64$). * The conversion loop iterates $\text{n\_digits}=26$ times, attempting to read 5 bits in each iteration, totaling $26 \times 5 = 130$ bits. * In the final iterations of the loop, the code attempts to read data that spans two limbs: C c = (r->tab[pos] >> shift) | (r->tab[pos + 1] << (JS_LIMB_BITS - shift)); * Since the BigInt was only allocated two limbs, the read operation for r->tab[pos + 1] becomes an Out-of-Bounds Read when pos points to the last valid limb (e.g., $pos=1$). This vulnerability allows an attacker to cause the engine to read and process data from the memory immediately following the BigInt buffer. This can lead to Information Disclosure of sensitive data stored on the heap adjacent to the BigInt object. | ||||
| CVE-2025-62495 | 2 Quickjs-ng, Quickjs Project | 2 Quickjs, Quickjs | 2025-10-29 | 8.8 High |
| An integer overflow vulnerability exists in the QuickJS regular expression engine (libregexp) due to an inconsistent representation of the bytecode buffer size. * The regular expression bytecode is stored in a DynBuf structure, which correctly uses a $\text{size}\_\text{t}$ (an unsigned type, typically 64-bit) for its size member. * However, several functions, such as re_emit_op_u32 and other internal parsing routines, incorrectly cast or store this DynBuf $\text{size}\_\text{t}$ value into a signed int (typically 32-bit). * When a large or complex regular expression (such as those generated by a recursive pattern in a Proof-of-Concept) causes the bytecode size to exceed $2^{31}$ bytes (the maximum positive value for a signed 32-bit integer), the size value wraps around, resulting in a negative integer when stored in the int variable (Integer Overflow). * This negative value is subsequently used in offset calculations. For example, within functions like re_parse_disjunction, the negative size is used to compute an offset (pos) for patching a jump instruction. * This negative offset is then incorrectly added to the buffer pointer (s->byte\_code.buf + pos), leading to an out-of-bounds write on the first line of the snippet below: put_u32(s->byte_code.buf + pos, len); | ||||
| CVE-2025-10456 | 2 Zephyrproject, Zephyrproject-rtos | 2 Zephyr, Zephyr | 2025-10-29 | 7.1 High |
| A vulnerability was identified in the handling of Bluetooth Low Energy (BLE) fixed channels (such as SMP or ATT). Specifically, an attacker could exploit a flaw that causes the BLE target (i.e., the device under attack) to attempt to disconnect a fixed channel, which is not allowed per the Bluetooth specification. This leads to undefined behavior, including potential assertion failures, crashes, or memory corruption, depending on the BLE stack implementation. | ||||
| CVE-2025-10458 | 2 Zephyrproject, Zephyrproject-rtos | 2 Zephyr, Zephyr | 2025-10-29 | 7.6 High |
| Parameters are not validated or sanitized, and are later used in various internal operations. | ||||
| CVE-2025-7403 | 2 Zephyrproject, Zephyrproject-rtos | 2 Zephyr, Zephyr | 2025-10-29 | 7.6 High |
| Unsafe handling in bt_conn_tx_processor causes a use-after-free, resulting in a write-before-zero. The written 4 bytes are attacker-controlled, enabling precise memory corruption. | ||||
| CVE-2023-52987 | 1 Linux | 1 Linux Kernel | 2025-10-29 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-mtrace: prevent underflow in sof_ipc4_priority_mask_dfs_write() The "id" comes from the user. Change the type to unsigned to prevent an array underflow. | ||||
| CVE-2023-52995 | 1 Linux | 1 Linux Kernel | 2025-10-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: riscv/kprobe: Fix instruction simulation of JALR Set kprobe at 'jalr 1140(ra)' of vfs_write results in the following crash: [ 32.092235] Unable to handle kernel access to user memory without uaccess routines at virtual address 00aaaaaad77b1170 [ 32.093115] Oops [#1] [ 32.093251] Modules linked in: [ 32.093626] CPU: 0 PID: 135 Comm: ftracetest Not tainted 6.2.0-rc2-00013-gb0aa5e5df0cb-dirty #16 [ 32.093985] Hardware name: riscv-virtio,qemu (DT) [ 32.094280] epc : ksys_read+0x88/0xd6 [ 32.094855] ra : ksys_read+0xc0/0xd6 [ 32.095016] epc : ffffffff801cda80 ra : ffffffff801cdab8 sp : ff20000000d7bdc0 [ 32.095227] gp : ffffffff80f14000 tp : ff60000080f9cb40 t0 : ffffffff80f13e80 [ 32.095500] t1 : ffffffff8000c29c t2 : ffffffff800dbc54 s0 : ff20000000d7be60 [ 32.095716] s1 : 0000000000000000 a0 : ffffffff805a64ae a1 : ffffffff80a83708 [ 32.095921] a2 : ffffffff80f160a0 a3 : 0000000000000000 a4 : f229b0afdb165300 [ 32.096171] a5 : f229b0afdb165300 a6 : ffffffff80eeebd0 a7 : 00000000000003ff [ 32.096411] s2 : ff6000007ff76800 s3 : fffffffffffffff7 s4 : 00aaaaaad77b1170 [ 32.096638] s5 : ffffffff80f160a0 s6 : ff6000007ff76800 s7 : 0000000000000030 [ 32.096865] s8 : 00ffffffc3d97be0 s9 : 0000000000000007 s10: 00aaaaaad77c9410 [ 32.097092] s11: 0000000000000000 t3 : ffffffff80f13e48 t4 : ffffffff8000c29c [ 32.097317] t5 : ffffffff8000c29c t6 : ffffffff800dbc54 [ 32.097505] status: 0000000200000120 badaddr: 00aaaaaad77b1170 cause: 000000000000000d [ 32.098011] [<ffffffff801cdb72>] ksys_write+0x6c/0xd6 [ 32.098222] [<ffffffff801cdc06>] sys_write+0x2a/0x38 [ 32.098405] [<ffffffff80003c76>] ret_from_syscall+0x0/0x2 Since the rs1 and rd might be the same one, such as 'jalr 1140(ra)', hence it requires obtaining the target address from rs1 followed by updating rd. [Palmer: Pick Guo's cleanup] | ||||
| CVE-2024-10395 | 2 Zephyrproject, Zephyrproject-rtos | 2 Zephyr, Zephyr | 2025-10-29 | 8.6 High |
| No proper validation of the length of user input in http_server_get_content_type_from_extension. | ||||
| CVE-2019-1214 | 1 Microsoft | 16 Windows 10 1507, Windows 10 1607, Windows 10 1703 and 13 more | 2025-10-29 | 7.8 High |
| An elevation of privilege vulnerability exists when the Windows Common Log File System (CLFS) driver improperly handles objects in memory, aka 'Windows Common Log File System Driver Elevation of Privilege Vulnerability'. | ||||
| CVE-2020-0796 | 1 Microsoft | 4 Windows 10 1903, Windows 10 1909, Windows Server 1903 and 1 more | 2025-10-29 | 10.0 Critical |
| A remote code execution vulnerability exists in the way that the Microsoft Server Message Block 3.1.1 (SMBv3) protocol handles certain requests, aka 'Windows SMBv3 Client/Server Remote Code Execution Vulnerability'. | ||||
| CVE-2020-17087 | 1 Microsoft | 24 Windows 10, Windows 10 1507, Windows 10 1607 and 21 more | 2025-10-29 | 7.8 High |
| Windows Kernel Local Elevation of Privilege Vulnerability | ||||
| CVE-2025-61577 | 2 D-link, Dlink | 3 Dir-816a2, Dir-816, Dir-816 Firmware | 2025-10-29 | 7.5 High |
| D-Link DIR-816A2_FWv1.10CNB05 was discovered to contain a stack overflow via the statuscheckpppoeuser parameter in the dir_setWanWifi function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input. | ||||
| CVE-2025-58084 | 1 Mattermost | 2 Mattermost, Mattermost Desktop | 2025-10-29 | 3.5 Low |
| Mattermost Desktop App versions <= 5.13.0 fail to validate URLs external to the configured Mattermost servers, allowing an attacker on a server the user has configured to crash the user's application by sending the user a malformed URL. | ||||
| CVE-2025-62813 | 1 Lz4 Project | 1 Lz4 | 2025-10-29 | 5.9 Medium |
| DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none. | ||||
| CVE-2023-52933 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Rhel E4s | 2025-10-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Squashfs: fix handling and sanity checking of xattr_ids count A Sysbot [1] corrupted filesystem exposes two flaws in the handling and sanity checking of the xattr_ids count in the filesystem. Both of these flaws cause computation overflow due to incorrect typing. In the corrupted filesystem the xattr_ids value is 4294967071, which stored in a signed variable becomes the negative number -225. Flaw 1 (64-bit systems only): The signed integer xattr_ids variable causes sign extension. This causes variable overflow in the SQUASHFS_XATTR_*(A) macros. The variable is first multiplied by sizeof(struct squashfs_xattr_id) where the type of the sizeof operator is "unsigned long". On a 64-bit system this is 64-bits in size, and causes the negative number to be sign extended and widened to 64-bits and then become unsigned. This produces the very large number 18446744073709548016 or 2^64 - 3600. This number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0 (stored in len). Flaw 2 (32-bit systems only): On a 32-bit system the integer variable is not widened by the unsigned long type of the sizeof operator (32-bits), and the signedness of the variable has no effect due it always being treated as unsigned. The above corrupted xattr_ids value of 4294967071, when multiplied overflows and produces the number 4294963696 or 2^32 - 3400. This number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by SQUASHFS_METADATA_SIZE overflows again and produces a length of 0. The effect of the 0 length computation: In conjunction with the corrupted xattr_ids field, the filesystem also has a corrupted xattr_table_start value, where it matches the end of filesystem value of 850. This causes the following sanity check code to fail because the incorrectly computed len of 0 matches the incorrect size of the table reported by the superblock (0 bytes). len = SQUASHFS_XATTR_BLOCK_BYTES(*xattr_ids); indexes = SQUASHFS_XATTR_BLOCKS(*xattr_ids); /* * The computed size of the index table (len bytes) should exactly * match the table start and end points */ start = table_start + sizeof(*id_table); end = msblk->bytes_used; if (len != (end - start)) return ERR_PTR(-EINVAL); Changing the xattr_ids variable to be "usigned int" fixes the flaw on a 64-bit system. This relies on the fact the computation is widened by the unsigned long type of the sizeof operator. Casting the variable to u64 in the above macro fixes this flaw on a 32-bit system. It also means 64-bit systems do not implicitly rely on the type of the sizeof operator to widen the computation. [1] https://lore.kernel.org/lkml/000000000000cd44f005f1a0f17f@google.com/ | ||||
| CVE-2025-62496 | 2 Quickjs-ng, Quickjs Project | 2 Quickjs, Quickjs | 2025-10-28 | 8.8 High |
| A vulnerability exists in the QuickJS engine's BigInt string parsing logic (js_bigint_from_string) when attempting to create a BigInt from a string with an excessively large number of digits. The function calculates the necessary number of bits (n_bits) required to store the BigInt using the formula: $$\text{n\_bits} = (\text{n\_digits} \times 27 + 7) / 8 \quad (\text{for radix 10})$$ * For large input strings (e.g., $79,536,432$ digits or more for base 10), the intermediate calculation $(\text{n\_digits} \times 27 + 7)$ exceeds the maximum value of a standard signed 32-bit integer, resulting in an Integer Overflow. * The resulting n_bits value becomes unexpectedly small or even negative due to this wrap-around. * This flawed n_bits is then used to compute n_limbs, the number of memory "limbs" needed for the BigInt object. Since n_bits is too small, the calculated n_limbs is also significantly underestimated. * The function proceeds to allocate a JSBigInt object using this underestimated n_limbs. * When the function later attempts to write the actual BigInt data into the allocated object, the small buffer size is quickly exceeded, leading to a Heap Out-of-Bounds Write as data is written past the end of the allocated r->tab array. | ||||