Total
2461 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-45575 | 1 Qualcomm | 28 Fastconnect 6900, Fastconnect 6900 Firmware, Fastconnect 7800 and 25 more | 2025-05-09 | N/A | 7.8 HIGH |
| Memory corruption Camera kernel when large number of devices are attached through userspace. | |||||
| CVE-2022-37454 | 8 Debian, Extended Keccak Code Package Project, Fedoraproject and 5 more | 8 Debian Linux, Extended Keccak Code Package, Fedora and 5 more | 2025-05-08 | N/A | 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-2022-49885 | 1 Linux | 1 Linux Kernel | 2025-05-07 | N/A | 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-2025-22059 | 1 Linux | 1 Linux Kernel | 2025-05-06 | N/A | 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 | N/A | 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 | N/A | 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-2022-25315 | 5 Debian, Fedoraproject, Libexpat Project and 2 more | 6 Debian Linux, Fedora, Libexpat and 3 more | 2025-05-05 | 7.5 HIGH | 9.8 CRITICAL |
| In Expat (aka libexpat) before 2.4.5, there is an integer overflow in storeRawNames. | |||||
| CVE-2022-25314 | 5 Debian, Fedoraproject, Libexpat Project and 2 more | 6 Debian Linux, Fedora, Libexpat and 3 more | 2025-05-05 | 5.0 MEDIUM | 7.5 HIGH |
| In Expat (aka libexpat) before 2.4.5, there is an integer overflow in copyString. | |||||
| CVE-2022-22822 | 4 Debian, Libexpat Project, Siemens and 1 more | 4 Debian Linux, Libexpat, Sinema Remote Connect Server and 1 more | 2025-05-05 | 7.5 HIGH | 9.8 CRITICAL |
| addBinding in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. | |||||
| CVE-2022-23852 | 6 Debian, Libexpat Project, Netapp and 3 more | 7 Debian Linux, Libexpat, Clustered Data Ontap and 4 more | 2025-05-05 | 7.5 HIGH | 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-23567 | 1 Google | 1 Tensorflow | 2025-05-05 | 4.0 MEDIUM | 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. | |||||
| CVE-2022-22826 | 4 Debian, Libexpat Project, Siemens and 1 more | 4 Debian Linux, Libexpat, Sinema Remote Connect Server and 1 more | 2025-05-05 | 6.8 MEDIUM | 8.8 HIGH |
| nextScaffoldPart in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. | |||||
| CVE-2022-21738 | 1 Google | 1 Tensorflow | 2025-05-05 | 4.0 MEDIUM | 6.5 MEDIUM |
| Tensorflow is an Open Source Machine Learning Framework. The implementation of `SparseCountSparseOutput` can be made to crash a TensorFlow process by an integer overflow whose result is then used in a memory allocation. 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-22827 | 4 Debian, Libexpat Project, Siemens and 1 more | 4 Debian Linux, Libexpat, Sinema Remote Connect Server and 1 more | 2025-05-05 | 6.8 MEDIUM | 8.8 HIGH |
| storeAtts in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. | |||||
| CVE-2022-22825 | 4 Debian, Libexpat Project, Siemens and 1 more | 4 Debian Linux, Libexpat, Sinema Remote Connect Server and 1 more | 2025-05-05 | 6.8 MEDIUM | 8.8 HIGH |
| lookup in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. | |||||
| CVE-2022-21729 | 1 Google | 1 Tensorflow | 2025-05-05 | 4.0 MEDIUM | 6.5 MEDIUM |
| Tensorflow is an Open Source Machine Learning Framework. The implementation of `UnravelIndex` is vulnerable to a division by zero caused by an integer overflow bug. 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-23568 | 1 Google | 1 Tensorflow | 2025-05-05 | 4.0 MEDIUM | 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-2021-46143 | 4 Libexpat Project, Netapp, Siemens and 1 more | 8 Libexpat, Active Iq Unified Manager, Clustered Data Ontap and 5 more | 2025-05-05 | 6.8 MEDIUM | 7.8 HIGH |
| In doProlog in xmlparse.c in Expat (aka libexpat) before 2.4.3, an integer overflow exists for m_groupSize. | |||||
| CVE-2022-21727 | 1 Google | 1 Tensorflow | 2025-05-05 | 6.5 MEDIUM | 8.8 HIGH |
| Tensorflow is an Open Source Machine Learning Framework. The implementation of shape inference for `Dequantize` is vulnerable to an integer overflow weakness. The `axis` argument can be `-1` (the default value for the optional argument) or any other positive value at most the number of dimensions of the input. Unfortunately, the upper bound is not checked, and, since the code computes `axis + 1`, an attacker can trigger an integer overflow. 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-21733 | 1 Google | 1 Tensorflow | 2025-05-05 | 5.0 MEDIUM | 6.5 MEDIUM |
| Tensorflow is an Open Source Machine Learning Framework. The implementation of `StringNGrams` can be used to trigger a denial of service attack by causing an out of memory condition after an integer overflow. We are missing a validation on `pad_witdh` and that result in computing a negative value for `ngram_width` which is later used to allocate parts of the output. 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. | |||||