Total
3163 CVE
CVE | Vendors | Products | Updated | CVSS v3.1 |
---|---|---|---|---|
CVE-2022-37454 | 9 Debian, Extended Keccak Code Package Project, Fedoraproject and 6 more | 9 Debian Linux, Extended Keccak Code Package, Fedora and 6 more | 2025-05-08 | 9.8 Critical |
The Keccak XKCP SHA-3 reference implementation before fdc6fef has an integer overflow and resultant buffer overflow that allows attackers to execute arbitrary code or eliminate expected cryptographic properties. This occurs in the sponge function interface. | ||||
CVE-2024-21105 | 1 Oracle | 2 Solaris, Solaris Operating System | 2025-05-08 | 2 Low |
Vulnerability in the Oracle Solaris product of Oracle Systems (component: Utility). The supported version that is affected is 11. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where Oracle Solaris executes to compromise Oracle Solaris. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle Solaris accessible data. CVSS 3.1 Base Score 2.0 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:L/I:N/A:N). | ||||
CVE-2025-0690 | 1 Redhat | 2 Enterprise Linux, Openshift | 2025-05-07 | 6.1 Medium |
The read command is used to read the keyboard input from the user, while reads it keeps the input length in a 32-bit integer value which is further used to reallocate the line buffer to accept the next character. During this process, with a line big enough it's possible to make this variable to overflow leading to a out-of-bounds write in the heap based buffer. This flaw may be leveraged to corrupt grub's internal critical data and secure boot bypass is not discarded as consequence. | ||||
CVE-2024-45575 | 2025-05-07 | 7.8 High | ||
Memory corruption Camera kernel when large number of devices are attached through userspace. | ||||
CVE-2022-49885 | 1 Linux | 1 Linux Kernel | 2025-05-07 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init() Change num_ghes from int to unsigned int, preventing an overflow and causing subsequent vmalloc() to fail. The overflow happens in ghes_estatus_pool_init() when calculating len during execution of the statement below as both multiplication operands here are signed int: len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE); The following call trace is observed because of this bug: [ 9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1 [ 9.317131] Call Trace: [ 9.317134] <TASK> [ 9.317137] dump_stack_lvl+0x49/0x5f [ 9.317145] dump_stack+0x10/0x12 [ 9.317146] warn_alloc.cold+0x7b/0xdf [ 9.317150] ? __device_attach+0x16a/0x1b0 [ 9.317155] __vmalloc_node_range+0x702/0x740 [ 9.317160] ? device_add+0x17f/0x920 [ 9.317164] ? dev_set_name+0x53/0x70 [ 9.317166] ? platform_device_add+0xf9/0x240 [ 9.317168] __vmalloc_node+0x49/0x50 [ 9.317170] ? ghes_estatus_pool_init+0x43/0xa0 [ 9.317176] vmalloc+0x21/0x30 [ 9.317177] ghes_estatus_pool_init+0x43/0xa0 [ 9.317179] acpi_hest_init+0x129/0x19c [ 9.317185] acpi_init+0x434/0x4a4 [ 9.317188] ? acpi_sleep_proc_init+0x2a/0x2a [ 9.317190] do_one_initcall+0x48/0x200 [ 9.317195] kernel_init_freeable+0x221/0x284 [ 9.317200] ? rest_init+0xe0/0xe0 [ 9.317204] kernel_init+0x1a/0x130 [ 9.317205] ret_from_fork+0x22/0x30 [ 9.317208] </TASK> [ rjw: Subject and changelog edits ] | ||||
CVE-2024-23531 | 1 Ivanti | 1 Avalanche | 2025-05-06 | 7.5 High |
An Integer Overflow vulnerability in WLInfoRailService component of Ivanti Avalanche before 6.4.3 allows an unauthenticated remote attacker to perform denial of service attacks. In certain rare conditions this could also lead to reading content from memory. | ||||
CVE-2025-26642 | 2025-05-06 | 7.8 High | ||
Out-of-bounds read in Microsoft Office allows an unauthorized attacker to execute code locally. | ||||
CVE-2025-26639 | 2025-05-06 | 7.8 High | ||
Integer overflow or wraparound in Windows USB Print Driver allows an authorized attacker to elevate privileges locally. | ||||
CVE-2025-22059 | 1 Linux | 1 Linux Kernel | 2025-05-06 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: udp: Fix multiple wraparounds of sk->sk_rmem_alloc. __udp_enqueue_schedule_skb() has the following condition: if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) goto drop; sk->sk_rcvbuf is initialised by net.core.rmem_default and later can be configured by SO_RCVBUF, which is limited by net.core.rmem_max, or SO_RCVBUFFORCE. If we set INT_MAX to sk->sk_rcvbuf, the condition is always false as sk->sk_rmem_alloc is also signed int. Then, the size of the incoming skb is added to sk->sk_rmem_alloc unconditionally. This results in integer overflow (possibly multiple times) on sk->sk_rmem_alloc and allows a single socket to have skb up to net.core.udp_mem[1]. For example, if we set a large value to udp_mem[1] and INT_MAX to sk->sk_rcvbuf and flood packets to the socket, we can see multiple overflows: # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 7956736 <-- (7956736 << 12) bytes > INT_MAX * 15 ^- PAGE_SHIFT # ss -uam State Recv-Q ... UNCONN -1757018048 ... <-- flipping the sign repeatedly skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0) Previously, we had a boundary check for INT_MAX, which was removed by commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc"). A complete fix would be to revert it and cap the right operand by INT_MAX: rmem = atomic_add_return(size, &sk->sk_rmem_alloc); if (rmem > min(size + (unsigned int)sk->sk_rcvbuf, INT_MAX)) goto uncharge_drop; but we do not want to add the expensive atomic_add_return() back just for the corner case. Casting rmem to unsigned int prevents multiple wraparounds, but we still allow a single wraparound. # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> 12 # ss -uam State Recv-Q ... UNCONN -2147482816 ... <-- INT_MAX + 831 bytes skmem:(r2147484480,rb2147483646,t0,tb212992,f3264,w0,o0,bl0,d14468947) So, let's define rmem and rcvbuf as unsigned int and check skb->truesize only when rcvbuf is large enough to lower the overflow possibility. Note that we still have a small chance to see overflow if multiple skbs to the same socket are processed on different core at the same time and each size does not exceed the limit but the total size does. Note also that we must ignore skb->truesize for a small buffer as explained in commit 363dc73acacb ("udp: be less conservative with sock rmem accounting"). | ||||
CVE-2025-22080 | 1 Linux | 1 Linux Kernel | 2025-05-06 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Prevent integer overflow in hdr_first_de() The "de_off" and "used" variables come from the disk so they both need to check. The problem is that on 32bit systems if they're both greater than UINT_MAX - 16 then the check does work as intended because of an integer overflow. | ||||
CVE-2025-22081 | 1 Linux | 1 Linux Kernel | 2025-05-06 | 5.5 Medium |
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix a couple integer overflows on 32bit systems On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add(). | ||||
CVE-2025-21172 | 4 Apple, Linux, Microsoft and 1 more | 9 Macos, Linux Kernel, .net and 6 more | 2025-05-06 | 7.5 High |
.NET and Visual Studio Remote Code Execution Vulnerability | ||||
CVE-2025-47268 | 2025-05-06 | 6.5 Medium | ||
ping in iputils through 20240905 allows a denial of service (application error or incorrect data collection) via a crafted ICMP Echo Reply packet, because of a signed 64-bit integer overflow in timestamp multiplication. | ||||
CVE-2025-31203 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2025-05-05 | 6.5 Medium |
An integer overflow was addressed with improved input validation. This issue is fixed in macOS Sequoia 15.4, tvOS 18.4, iPadOS 17.7.6, macOS Sonoma 14.7.5, iOS 18.4 and iPadOS 18.4, watchOS 11.4, visionOS 2.4. An attacker on the local network may be able to cause a denial-of-service. | ||||
CVE-2022-25315 | 6 Debian, Fedoraproject, Libexpat Project and 3 more | 12 Debian Linux, Fedora, Libexpat and 9 more | 2025-05-05 | 9.8 Critical |
In Expat (aka libexpat) before 2.4.5, there is an integer overflow in storeRawNames. | ||||
CVE-2022-25314 | 6 Debian, Fedoraproject, Libexpat Project and 3 more | 8 Debian Linux, Fedora, Libexpat and 5 more | 2025-05-05 | 7.5 High |
In Expat (aka libexpat) before 2.4.5, there is an integer overflow in copyString. | ||||
CVE-2022-23990 | 7 Debian, Fedoraproject, Libexpat Project and 4 more | 8 Debian Linux, Fedora, Libexpat and 5 more | 2025-05-05 | 7.5 High |
Expat (aka libexpat) before 2.4.4 has an integer overflow in the doProlog function. | ||||
CVE-2022-23852 | 7 Debian, Libexpat Project, Netapp and 4 more | 10 Debian Linux, Libexpat, Clustered Data Ontap and 7 more | 2025-05-05 | 9.8 Critical |
Expat (aka libexpat) before 2.4.4 has a signed integer overflow in XML_GetBuffer, for configurations with a nonzero XML_CONTEXT_BYTES. | ||||
CVE-2022-23568 | 1 Google | 1 Tensorflow | 2025-05-05 | 6.5 Medium |
Tensorflow is an Open Source Machine Learning Framework. The implementation of `AddManySparseToTensorsMap` is vulnerable to an integer overflow which results in a `CHECK`-fail when building new `TensorShape` objects (so, an assert failure based denial of service). We are missing some validation on the shapes of the input tensors as well as directly constructing a large `TensorShape` with user-provided dimensions. The fix will be included in TensorFlow 2.8.0. We will also cherrypick this commit on TensorFlow 2.7.1, TensorFlow 2.6.3, and TensorFlow 2.5.3, as these are also affected and still in supported range. | ||||
CVE-2022-23567 | 1 Google | 1 Tensorflow | 2025-05-05 | 6.5 Medium |
Tensorflow is an Open Source Machine Learning Framework. The implementations of `Sparse*Cwise*` ops are vulnerable to integer overflows. These can be used to trigger large allocations (so, OOM based denial of service) or `CHECK`-fails when building new `TensorShape` objects (so, assert failures based denial of service). We are missing some validation on the shapes of the input tensors as well as directly constructing a large `TensorShape` with user-provided dimensions. The fix will be included in TensorFlow 2.8.0. We will also cherrypick this commit on TensorFlow 2.7.1, TensorFlow 2.6.3, and TensorFlow 2.5.3, as these are also affected and still in supported range. |