Total
381 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-23109 | 1 Crasm Project | 1 Crasm | 2025-03-11 | 7.5 High |
| In crasm 1.8-3, invalid input validation, specific files passed to the command line application, can lead to a divide by zero fault in the function opdiv. | ||||
| CVE-2023-1127 | 2 Fedoraproject, Vim | 2 Fedora, Vim | 2025-03-07 | 7.8 High |
| Divide By Zero in GitHub repository vim/vim prior to 9.0.1367. | ||||
| CVE-2024-1298 | 2 Redhat, Tianocore | 6 Enterprise Linux, Rhel Aus, Rhel E4s and 3 more | 2025-03-07 | 6 Medium |
| EDK2 contains a vulnerability when S3 sleep is activated where an Attacker may cause a Division-By-Zero due to a UNIT32 overflow via local access. A successful exploit of this vulnerability may lead to a loss of Availability. | ||||
| CVE-2024-27239 | 2025-03-06 | 4.3 Medium | ||
| Use after free in some Zoom Workplace Apps and SDKs may allow an authenticated user to conduct a denial of service via network access. | ||||
| CVE-2019-13454 | 5 Canonical, Debian, Imagemagick and 2 more | 5 Ubuntu Linux, Debian Linux, Imagemagick and 2 more | 2025-03-04 | 6.5 Medium |
| ImageMagick 7.0.1-0 to 7.0.8-54 Q16 allows Division by Zero in RemoveDuplicateLayers in MagickCore/layer.c. | ||||
| CVE-2024-57922 | 1 Linux | 1 Linux Kernel | 2025-02-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add check for granularity in dml ceil/floor helpers [Why] Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2() should check for granularity is non zero to avoid assert and divide-by-zero error in dcn_bw_ functions. [How] Add check for granularity 0. (cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec) | ||||
| CVE-2024-26778 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-02-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fbdev: savage: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. Although pixclock is checked in savagefb_decode_var(), but it is not checked properly in savagefb_probe(). Fix this by checking whether pixclock is zero in the function savagefb_check_var() before info->var.pixclock is used as the divisor. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8. | ||||
| CVE-2024-26777 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-02-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fbdev: sis: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. In sisfb_check_var(), var->pixclock is used as a divisor to caculate drate before it is checked against zero. Fix this by checking it at the beginning. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8. | ||||
| CVE-2024-26774 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-02-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt Determine if bb_fragments is 0 instead of determining bb_free to eliminate the risk of dividing by zero when the block bitmap is corrupted. | ||||
| CVE-2024-57950 | 1 Linux | 1 Linux Kernel | 2025-02-21 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominator defaults to 1 [WHAT & HOW] Variables, used as denominators and maybe not assigned to other values, should be initialized to non-zero to avoid DIVIDE_BY_ZERO, as reported by Coverity. (cherry picked from commit e2c4c6c10542ccfe4a0830bb6c9fd5b177b7bbb7) | ||||
| CVE-2024-57919 | 1 Linux | 1 Linux Kernel | 2025-02-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix divide error in DM plane scale calcs dm_get_plane_scale doesn't take into account plane scaled size equal to zero, leading to a kernel oops due to division by zero. Fix by setting out-scale size as zero when the dst size is zero, similar to what is done by drm_calc_scale(). This issue started with the introduction of cursor ovelay mode that uses this function to assess cursor mode changes via dm_crtc_get_cursor_mode() before checking plane state. [Dec17 17:14] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI [ +0.000018] CPU: 5 PID: 1660 Comm: surface-DP-1 Not tainted 6.10.0+ #231 [ +0.000007] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024 [ +0.000004] RIP: 0010:dm_get_plane_scale+0x3f/0x60 [amdgpu] [ +0.000553] Code: 44 0f b7 41 3a 44 0f b7 49 3e 83 e0 0f 48 0f a3 c2 73 21 69 41 28 e8 03 00 00 31 d2 41 f7 f1 31 d2 89 06 69 41 2c e8 03 00 00 <41> f7 f0 89 07 e9 d7 d8 7e e9 44 89 c8 45 89 c1 41 89 c0 eb d4 66 [ +0.000005] RSP: 0018:ffffa8df0de6b8a0 EFLAGS: 00010246 [ +0.000006] RAX: 00000000000003e8 RBX: ffff9ac65c1f6e00 RCX: ffff9ac65d055500 [ +0.000003] RDX: 0000000000000000 RSI: ffffa8df0de6b8b0 RDI: ffffa8df0de6b8b4 [ +0.000004] RBP: ffff9ac64e7a5800 R08: 0000000000000000 R09: 0000000000000a00 [ +0.000003] R10: 00000000000000ff R11: 0000000000000054 R12: ffff9ac6d0700010 [ +0.000003] R13: ffff9ac65d054f00 R14: ffff9ac65d055500 R15: ffff9ac64e7a60a0 [ +0.000004] FS: 00007f869ea00640(0000) GS:ffff9ac970080000(0000) knlGS:0000000000000000 [ +0.000004] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000003] CR2: 000055ca701becd0 CR3: 000000010e7f2000 CR4: 0000000000350ef0 [ +0.000004] Call Trace: [ +0.000007] <TASK> [ +0.000006] ? __die_body.cold+0x19/0x27 [ +0.000009] ? die+0x2e/0x50 [ +0.000007] ? do_trap+0xca/0x110 [ +0.000007] ? do_error_trap+0x6a/0x90 [ +0.000006] ? dm_get_plane_scale+0x3f/0x60 [amdgpu] [ +0.000504] ? exc_divide_error+0x38/0x50 [ +0.000005] ? dm_get_plane_scale+0x3f/0x60 [amdgpu] [ +0.000488] ? asm_exc_divide_error+0x1a/0x20 [ +0.000011] ? dm_get_plane_scale+0x3f/0x60 [amdgpu] [ +0.000593] dm_crtc_get_cursor_mode+0x33f/0x430 [amdgpu] [ +0.000562] amdgpu_dm_atomic_check+0x2ef/0x1770 [amdgpu] [ +0.000501] drm_atomic_check_only+0x5e1/0xa30 [drm] [ +0.000047] drm_mode_atomic_ioctl+0x832/0xcb0 [drm] [ +0.000050] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [drm] [ +0.000047] drm_ioctl_kernel+0xb3/0x100 [drm] [ +0.000062] drm_ioctl+0x27a/0x4f0 [drm] [ +0.000049] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 [drm] [ +0.000055] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu] [ +0.000360] __x64_sys_ioctl+0x97/0xd0 [ +0.000010] do_syscall_64+0x82/0x190 [ +0.000008] ? __pfx_drm_mode_createblob_ioctl+0x10/0x10 [drm] [ +0.000044] ? srso_return_thunk+0x5/0x5f [ +0.000006] ? drm_ioctl_kernel+0xb3/0x100 [drm] [ +0.000040] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? __check_object_size+0x50/0x220 [ +0.000007] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? drm_ioctl+0x2a4/0x4f0 [drm] [ +0.000039] ? __pfx_drm_mode_createblob_ioctl+0x10/0x10 [drm] [ +0.000043] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? __pm_runtime_suspend+0x69/0xc0 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? amdgpu_drm_ioctl+0x71/0x90 [amdgpu] [ +0.000366] ? srso_return_thunk+0x5/0x5f [ +0.000006] ? syscall_exit_to_user_mode+0x77/0x210 [ +0.000007] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? do_syscall_64+0x8e/0x190 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000006] ? do_syscall_64+0x8e/0x190 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000007] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000008] RIP: 0033:0x55bb7cd962bc [ +0.000007] Code: 4c 89 6c 24 18 4c 89 64 24 20 4c 89 74 24 28 0f 57 c0 0f 11 44 24 30 89 c7 48 8d 54 24 08 b8 10 00 00 00 be bc 64 ---truncated--- | ||||
| CVE-2023-3896 | 1 Vim | 1 Vim | 2025-02-13 | 7.8 High |
| Divide By Zero in vim/vim from 9.0.1367-1 to 9.0.1367-3 | ||||
| CVE-2023-2906 | 1 Wireshark | 1 Wireshark | 2025-02-13 | 6.5 Medium |
| Due to a failure in validating the length provided by an attacker-crafted CP2179 packet, Wireshark versions 2.0.0 through 4.0.7 is susceptible to a divide by zero allowing for a denial of service attack. | ||||
| CVE-2023-46849 | 3 Debian, Fedoraproject, Openvpn | 4 Debian Linux, Fedora, Openvpn and 1 more | 2025-02-13 | 7.5 High |
| Using the --fragment option in certain configuration setups OpenVPN version 2.6.0 to 2.6.6 allows an attacker to trigger a divide by zero behaviour which could cause an application crash, leading to a denial of service. | ||||
| CVE-2024-57598 | 2025-02-06 | 6.5 Medium | ||
| A floating point exception (divide-by-zero) vulnerability was discovered in Bento4 1.6.0-641 in function AP4_TfraAtom() of Ap4TfraAtom.cpp which allows a remote attacker to cause a denial of service vulnerability. | ||||
| CVE-2023-25511 | 3 Linux, Microsoft, Nvidia | 3 Linux Kernel, Windows, Cuda Toolkit | 2025-02-04 | 3.3 Low |
| NVIDIA CUDA Toolkit for Linux and Windows contains a vulnerability in cuobjdump, where a division-by-zero error may enable a user to cause a crash, which may lead to a limited denial of service. | ||||
| CVE-2024-4785 | 1 Zephyrproject | 1 Zephyr | 2025-02-03 | 7.6 High |
| BT: Missing Check in LL_CONNECTION_UPDATE_IND Packet Leads to Division by Zero | ||||
| CVE-2023-29659 | 2 Fedoraproject, Struktur | 2 Fedora, Libheif | 2025-01-29 | 6.5 Medium |
| A Segmentation fault caused by a floating point exception exists in libheif 1.15.1 using crafted heif images via the heif::Fraction::round() function in box.cc, which causes a denial of service. | ||||
| CVE-2023-32573 | 2 Qt, Redhat | 2 Qt, Enterprise Linux | 2025-01-27 | 6.5 Medium |
| In Qt before 5.15.14, 6.0.x through 6.2.x before 6.2.9, and 6.3.x through 6.5.x before 6.5.1, QtSvg QSvgFont m_unitsPerEm initialization is mishandled. | ||||
| CVE-2023-2662 | 1 Xpdfreader | 1 Xpdf | 2025-01-24 | 2.9 Low |
| In Xpdf 4.04 (and earlier), a bad color space object in the input PDF file can cause a divide-by-zero. | ||||