| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A floating point exception (divide-by-zero) issue was discovered in SoX in functon read_samples() of voc.c file. An attacker with a crafted file, could cause an application to crash. |
| A floating point exception (divide-by-zero) issue was discovered in SoX in functon startread() of wav.c file. An attacker with a crafted wav file, could cause an application to crash. |
| An issue in redoxOS kernel before commit 5d41cd7c allows a local attacker to cause a denial of service via the `setitimer` syscall |
| Divide-by-zero in Clickhouse's Gorilla compression codec when parsing a malicious query. The first byte of the compressed buffer is used in a modulo operation without being checked for 0. |
| Divide-by-zero in Clickhouse's DeltaDouble compression codec when parsing a malicious query. The first byte of the compressed buffer is used in a modulo operation without being checked for 0. |
| Divide-by-zero in Clickhouse's Delta compression codec when parsing a malicious query. The first byte of the compressed buffer is used in a modulo operation without being checked for 0. |
| In the Linux kernel, the following vulnerability has been resolved:
libnvdimm/labels: Fix divide error in nd_label_data_init()
If a faulty CXL memory device returns a broken zero LSA size in its
memory device information (Identify Memory Device (Opcode 4000h), CXL
spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm
driver:
Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]
Code and flow:
1) CXL Command 4000h returns LSA size = 0
2) config_size is assigned to zero LSA size (CXL pmem driver):
drivers/cxl/pmem.c: .config_size = mds->lsa_size,
3) max_xfer is set to zero (nvdimm driver):
drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size);
4) A subsequent DIV_ROUND_UP() causes a division by zero:
drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */
drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,
drivers/nvdimm/label.c- config_size);
Fix this by checking the config size parameter by extending an
existing check. |
| An issue was discovered in FastNetMon Community Edition through 1.2.7. Zero-length templates for Netflow v9 allow remote attackers to cause a denial of service (divide-by-zero error and application crash). |
| 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. |
| FPE in paddle.argmin and paddle.argmax in PaddlePaddle before 2.6.0. This flaw can cause a runtime crash and a denial of service.
|
| 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. |
| FPE in paddle.nanmedian in PaddlePaddle before 2.6.0. This flaw can cause a runtime crash and a denial of service.
|
| FPE in paddle.topk in PaddlePaddle before 2.6.0. This flaw can cause a runtime crash and a denial of service.
|
| FPE in paddle.lerp in PaddlePaddle before 2.6.0. This flaw can cause a runtime crash and a denial of service.
|
| In the memory_pages crate 0.1.0 for Rust, division by zero can occur. |
| FPE in paddle.linalg.matrix_rank in PaddlePaddle before 2.6.0. This flaw can cause a runtime crash and a denial of service.
|
| Divide By Zero vulnerability in davisking dlib allows
remote attackers to cause a denial of service via a crafted file.
.This issue affects dlib: before <19.24.7. |
| 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. |
| A divide by zero vulnerability exists in ollama/ollama version v0.3.3. The vulnerability occurs when importing GGUF models with a crafted type for `block_count` in the Modelfile. This can lead to a denial of service (DoS) condition when the server processes the model, causing it to crash. |
| FPE in paddle.amin in PaddlePaddle before 2.6.0. This flaw can cause a runtime crash and a denial of service.
|
