CWE-682
DiscouragedIncorrect Calculation
Abstraction: Pillar · Status: Draft
The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
180 vulnerabilities reference this CWE, most recent first.
GHSA-FWQV-682V-F9JF
Vulnerability from github – Published: 2024-11-20 09:32 – Updated: 2026-02-23 12:31Improper access control vulnerability in M-Files Aino in versions before 24.10 allowed an authenticated user to access object information via incorrect calculation of effective permissions.
{
"affected": [],
"aliases": [
"CVE-2024-11176"
],
"database_specific": {
"cwe_ids": [
"CWE-682",
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-20T09:15:04Z",
"severity": "MODERATE"
},
"details": "Improper access control vulnerability in M-Files Aino in versions before 24.10 allowed an authenticated user to access object information via incorrect calculation of effective permissions.",
"id": "GHSA-fwqv-682v-f9jf",
"modified": "2026-02-23T12:31:29Z",
"published": "2024-11-20T09:32:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11176"
},
{
"type": "WEB",
"url": "https://empower.m-files.com/security-advisories/CVE-2024-11176"
},
{
"type": "WEB",
"url": "https://product.m-files.com/security-advisories/CVE-2024-11176"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-G2CH-2WMH-HPHV
Vulnerability from github – Published: 2022-05-13 01:42 – Updated: 2025-04-20 03:41When ImageMagick 7.0.6-1 processes a crafted file in convert, it can lead to a Floating Point Exception (FPE) in the WritePALMImage() function in coders/palm.c, related to an incorrect bits-per-pixel calculation.
{
"affected": [],
"aliases": [
"CVE-2017-11537"
],
"database_specific": {
"cwe_ids": [
"CWE-682"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-07-23T03:29:00Z",
"severity": "MODERATE"
},
"details": "When ImageMagick 7.0.6-1 processes a crafted file in convert, it can lead to a Floating Point Exception (FPE) in the WritePALMImage() function in coders/palm.c, related to an incorrect bits-per-pixel calculation.",
"id": "GHSA-g2ch-2wmh-hphv",
"modified": "2025-04-20T03:41:17Z",
"published": "2022-05-13T01:42:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-11537"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/560"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/05/msg00015.html"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3681-1"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2017/dsa-4019"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GFFV-5HR2-F9GJ
Vulnerability from github – Published: 2021-08-25 20:43 – Updated: 2023-06-13 20:12Affected versions of this crate did not properly reset a streaming state. Resetting a streaming state, without finalising it first, creates incorrect results. The flaw was corrected by not first checking if the state had already been reset, when calling reset().
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "orion"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.11.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-20999"
],
"database_specific": {
"cwe_ids": [
"CWE-682"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-19T21:24:37Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Affected versions of this crate did not properly reset a streaming state. Resetting a streaming state, without finalising it first, creates incorrect results. The flaw was corrected by not first checking if the state had already been reset, when calling reset().",
"id": "GHSA-gffv-5hr2-f9gj",
"modified": "2023-06-13T20:12:57Z",
"published": "2021-08-25T20:43:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20999"
},
{
"type": "WEB",
"url": "https://github.com/brycx/orion/issues/46"
},
{
"type": "PACKAGE",
"url": "https://github.com/brycx/orion"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2018-0012.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Flaw in streaming state in orion"
}
GHSA-GFV7-9JPR-9XM8
Vulnerability from github – Published: 2022-05-24 22:00 – Updated: 2024-06-06 21:30ngiflib 0.4 has a heap-based buffer overflow in WritePixels() in ngiflib.c when called from DecodeGifImg, because deinterlacing for small pictures is mishandled.
{
"affected": [],
"aliases": [
"CVE-2019-16347"
],
"database_specific": {
"cwe_ids": [
"CWE-682"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-09-16T13:15:00Z",
"severity": "MODERATE"
},
"details": "ngiflib 0.4 has a heap-based buffer overflow in WritePixels() in ngiflib.c when called from DecodeGifImg, because deinterlacing for small pictures is mishandled.",
"id": "GHSA-gfv7-9jpr-9xm8",
"modified": "2024-06-06T21:30:35Z",
"published": "2022-05-24T22:00:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16347"
},
{
"type": "WEB",
"url": "https://github.com/miniupnp/ngiflib/issues/12"
},
{
"type": "WEB",
"url": "https://github.com/miniupnp/ngiflib/commit/37d939a6f511d16d4c95678025c235fe62e6417a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GGV6-7VFJ-R2FW
Vulnerability from github – Published: 2024-02-13 21:30 – Updated: 2025-03-17 18:31Due to a code bug in Secure_TSC, SEV firmware may allow an attacker with high privileges to cause a guest to observe an incorrect TSC when Secure TSC is enabled potentially resulting in a loss of guest integrity.
{
"affected": [],
"aliases": [
"CVE-2023-31347"
],
"database_specific": {
"cwe_ids": [
"CWE-682"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-13T20:15:52Z",
"severity": "MODERATE"
},
"details": "Due to a code bug in\nSecure_TSC, SEV firmware may allow an attacker with high privileges to cause a\nguest to observe an incorrect TSC when Secure TSC is enabled potentially\nresulting in a loss of guest integrity. \u00a0",
"id": "GHSA-ggv6-7vfj-r2fw",
"modified": "2025-03-17T18:31:37Z",
"published": "2024-02-13T21:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31347"
},
{
"type": "WEB",
"url": "https://www.amd.com/en/corporate/product-security/bulletin/AMD-SB-3007"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GJM7-VCH5-HCH8
Vulnerability from github – Published: 2026-06-25 21:31 – Updated: 2026-06-26 18:33The X25519 x86_64 assembly implementation fails to clear the most significant bit during the final modular reduction, so the computed result may not be fully reduced modulo the field prime 2^255 - 19. This can leave the field element in a non-canonical form, producing an incorrect result from the scalar multiplication and potentially a wrong shared secret. The final carry-propagation chains in the x64 and AVX2 reduction routines could overflow into the top bit, and the high limb was not masked afterward, so the 255-bit field element was left non-canonical.
{
"affected": [],
"aliases": [
"CVE-2026-10512"
],
"database_specific": {
"cwe_ids": [
"CWE-682"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T20:17:09Z",
"severity": "LOW"
},
"details": "The X25519 x86_64 assembly implementation fails to clear the most significant bit during the final modular reduction, so the computed result may not be fully reduced modulo the field prime 2^255 - 19. This can leave the field element in a non-canonical form, producing an incorrect result from the scalar multiplication and potentially a wrong shared secret. The final carry-propagation chains in the x64 and AVX2 reduction routines could overflow into the top bit, and the high limb was not masked afterward, so the 255-bit field element was left non-canonical.",
"id": "GHSA-gjm7-vch5-hch8",
"modified": "2026-06-26T18:33:50Z",
"published": "2026-06-25T21:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10512"
},
{
"type": "WEB",
"url": "https://github.com/wolfSSL/wolfssl/pull/10536"
},
{
"type": "WEB",
"url": "https://www.wolfssl.com/docs/security-vulnerabilities"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-GWFM-9VVH-63R3
Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2022-08-05 00:00In Go before 1.14.14 and 1.15.x before 1.15.7, crypto/elliptic/p224.go can generate incorrect outputs, related to an underflow of the lowest limb during the final complete reduction in the P-224 field.
{
"affected": [],
"aliases": [
"CVE-2021-3114"
],
"database_specific": {
"cwe_ids": [
"CWE-682"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-26T18:16:00Z",
"severity": "MODERATE"
},
"details": "In Go before 1.14.14 and 1.15.x before 1.15.7, crypto/elliptic/p224.go can generate incorrect outputs, related to an underflow of the lowest limb during the final complete reduction in the P-224 field.",
"id": "GHSA-gwfm-9vvh-63r3",
"modified": "2022-08-05T00:00:27Z",
"published": "2022-05-24T17:40:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3114"
},
{
"type": "WEB",
"url": "https://github.com/golang/go/commit/d95ca9138026cbe40e0857d76a81a16d03230871"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/golang-announce/c/mperVMGa98w"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/03/msg00014.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/03/msg00015.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YWAYJGXWC232SG3UR3TR574E6BP3OSQQ"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202208-02"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210219-0001"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4848"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GWVV-GR8W-GGVQ
Vulnerability from github – Published: 2024-06-24 18:31 – Updated: 2024-06-24 18:31Incorrect Calculation vulnerability in Renesas arm-trusted-firmware allows Local Execution of Code.
When checking whether a new image invades/overlaps with a previously loaded image the code neglects to consider a few cases. that could An attacker to bypass memory range restriction and overwrite an already loaded image partly or completely, which could result in code execution and bypass of secure boot.
{
"affected": [],
"aliases": [
"CVE-2024-6287"
],
"database_specific": {
"cwe_ids": [
"CWE-682"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-24T16:15:11Z",
"severity": "HIGH"
},
"details": "Incorrect Calculation vulnerability in Renesas arm-trusted-firmware allows Local Execution of Code.\n\n\nWhen checking whether a new image invades/overlaps with a previously loaded image the code neglects to consider a few cases. that could An attacker to bypass memory range restriction and overwrite an already loaded image partly or completely, which could result in code execution and bypass of secure boot.",
"id": "GHSA-gwvv-gr8w-ggvq",
"modified": "2024-06-24T18:31:36Z",
"published": "2024-06-24T18:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6287"
},
{
"type": "WEB",
"url": "https://github.com/renesas-rcar/arm-trusted-firmware/commit/954d488a9798f8fda675c6b57c571b469b298f04"
},
{
"type": "WEB",
"url": "https://asrg.io/security-advisories/cve-2024-6287"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H37V-HP6W-2PP8
Vulnerability from github – Published: 2026-02-02 20:33 – Updated: 2026-02-02 20:33Summary
There's a bug in the use_hint function where it adds 1 instead of subtracting 1 when the decomposed low bits r0 equal exactly zero. FIPS 204 Algorithm 40 is pretty clear that r0 > 0 means strictly positive, but the current code treats zero as positive. This causes valid signatures to potentially fail verification when this edge case gets hit.
Details
The issue is in ml-dsa/src/hint.rs in the use_hint function. Here's what FIPS 204 Algorithm 40 says:
3: if h = 1 and r0 > 0 return (r1 + 1) mod m
4: if h = 1 and r0 <= 0 return (r1 − 1) mod m
Line 3 uses r0 > 0 (strictly greater than zero), and line 4 uses r0 <= 0 (less than or equal, which includes zero). So when r0 = 0, the spec says to subtract 1.
But the current implementation does this:
if h && r0.0 <= gamma2 {
Elem::new((r1.0 + 1) % m)
} else if h && r0.0 >= BaseField::Q - gamma2 {
Elem::new((r1.0 + m - 1) % m)
}
The problem is r0.0 <= gamma2 includes zero. When r0 = 0, this condition is true (since 0 <= gamma2), so it adds 1. But according to the spec, r0 = 0 should fall into the r0 <= 0 case and subtract 1 instead.
The result is +1 when it should be -1, which is an off by two error mod m.
PoC
Take MLDSA 44 where γ2 = 95,232 and m = 44.
If use_hint(true, 0) is called:
- Decompose(0) gives (r1=0, r0=0)
- The condition r0.0 <= gamma2 is 0 <= 95232 which is true
- So it returns (0 + 1) % 44 = 1
But FIPS 204 says:
- r0 > 0 is 0 > 0 which is false
- r0 ≤ 0 is 0 ≤ 0 which is true
- So it should return (0 - 1) mod 44 = 43
The function returns 1 when it should return 43.
This can happen in real signatures whenever any coefficient of the w' vector happens to be a multiple of 2γ2, which makes its decomposed r0 equal zero. It's not super common but it's definitely possible, and when it hits, verification will fail for a completely valid signature.
Impact
This is a FIPS 204 compliance bug that affects signature verification. When the edge case triggers, valid signatures get rejected. Since MLDSA is supposed to be used for high security post quantum cryptography, having verification randomly fail isn't great. It's also theoretically possible that the mismatch between what signing expects and what verification does could be exploited somehow, though that would need more looking into.
The fix is straightforward, just change the condition to explicitly check for positive values:
if h && r0.0 > 0 && r0.0 <= gamma2 {
Elem::new((r1.0 + 1) % m)
} else if h {
Elem::new((r1.0 + m - 1) % m)
}
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.1.0-rc.4"
},
"package": {
"ecosystem": "crates.io",
"name": "ml-dsa"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.0-rc.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-193",
"CWE-682"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-02T20:33:08Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nThere\u0027s a bug in the `use_hint` function where it adds 1 instead of subtracting 1 when the decomposed low bits `r0` equal exactly zero. FIPS 204 Algorithm 40 is pretty clear that `r0 \u003e 0` means strictly positive, but the current code treats zero as positive. This causes valid signatures to potentially fail verification when this edge case gets hit.\n\n### Details\n\nThe issue is in `ml-dsa/src/hint.rs` in the `use_hint` function. Here\u0027s what FIPS 204 Algorithm 40 says:\n\n```\n3: if h = 1 and r0 \u003e 0 return (r1 + 1) mod m\n4: if h = 1 and r0 \u003c= 0 return (r1 \u2212 1) mod m\n```\n\nLine 3 uses `r0 \u003e 0` (strictly greater than zero), and line 4 uses `r0 \u003c= 0` (less than or equal, which includes zero). So when `r0 = 0`, the spec says to subtract 1.\n\nBut the current implementation does this:\n\n```rust\nif h \u0026\u0026 r0.0 \u003c= gamma2 {\n Elem::new((r1.0 + 1) % m)\n} else if h \u0026\u0026 r0.0 \u003e= BaseField::Q - gamma2 {\n Elem::new((r1.0 + m - 1) % m)\n}\n```\n\nThe problem is `r0.0 \u003c= gamma2` includes zero. When `r0 = 0`, this condition is true (since `0 \u003c= gamma2`), so it adds 1. But according to the spec, `r0 = 0` should fall into the `r0 \u003c= 0` case and subtract 1 instead.\n\nThe result is +1 when it should be -1, which is an off by two error mod m.\n\n### PoC\n\nTake MLDSA 44 where \u03b32 = 95,232 and m = 44.\n\nIf `use_hint(true, 0)` is called:\n- `Decompose(0)` gives `(r1=0, r0=0)`\n- The condition `r0.0 \u003c= gamma2` is `0 \u003c= 95232` which is true\n- So it returns `(0 + 1) % 44 = 1`\n\nBut FIPS 204 says:\n- `r0 \u003e 0` is `0 \u003e 0` which is false\n- `r0 \u2264 0` is `0 \u2264 0` which is true\n- So it should return `(0 - 1) mod 44 = 43`\n\nThe function returns 1 when it should return 43.\n\nThis can happen in real signatures whenever any coefficient of the `w\u0027` vector happens to be a multiple of 2\u03b32, which makes its decomposed `r0` equal zero. It\u0027s not super common but it\u0027s definitely possible, and when it hits, verification will fail for a completely valid signature.\n\n### Impact\n\nThis is a FIPS 204 compliance bug that affects signature verification. When the edge case triggers, valid signatures get rejected. Since MLDSA is supposed to be used for high security post quantum cryptography, having verification randomly fail isn\u0027t great. It\u0027s also theoretically possible that the mismatch between what signing expects and what verification does could be exploited somehow, though that would need more looking into.\n\nThe fix is straightforward, just change the condition to explicitly check for positive values:\n\n```rust\nif h \u0026\u0026 r0.0 \u003e 0 \u0026\u0026 r0.0 \u003c= gamma2 {\n Elem::new((r1.0 + 1) % m)\n} else if h {\n Elem::new((r1.0 + m - 1) % m)\n}\n```",
"id": "GHSA-h37v-hp6w-2pp8",
"modified": "2026-02-02T20:33:08Z",
"published": "2026-02-02T20:33:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/RustCrypto/signatures/security/advisories/GHSA-h37v-hp6w-2pp8"
},
{
"type": "WEB",
"url": "https://github.com/RustCrypto/signatures/commit/10f4ff04cb43ef2b789ee06e885f11cd054b1335"
},
{
"type": "PACKAGE",
"url": "https://github.com/RustCrypto/signatures"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "ml-dsa\u0027s UseHint function has off by two error when r0 equals zero"
}
GHSA-H3Q3-FXJ2-H3Q7
Vulnerability from github – Published: 2022-04-16 00:00 – Updated: 2022-04-23 00:03An issue was discovered in YottaDB through r1.32 and V7.0-000. Using crafted input, attackers can cause a calculation of the size of calls to memset in op_fnj3 in sr_port/op_fnj3.c to result in an extremely large value in order to cause a segmentation fault and crash the application. This is a "- (digs < 1 ? 1 : digs)" subtraction.
{
"affected": [],
"aliases": [
"CVE-2021-44490"
],
"database_specific": {
"cwe_ids": [
"CWE-682"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-15T18:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in YottaDB through r1.32 and V7.0-000. Using crafted input, attackers can cause a calculation of the size of calls to memset in op_fnj3 in sr_port/op_fnj3.c to result in an extremely large value in order to cause a segmentation fault and crash the application. This is a \"- (digs \u003c 1 ? 1 : digs)\" subtraction.",
"id": "GHSA-h3q3-fxj2-h3q7",
"modified": "2022-04-23T00:03:15Z",
"published": "2022-04-16T00:00:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44490"
},
{
"type": "WEB",
"url": "https://gitlab.com/YottaDB/DB/YDB/-/issues/828"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Understand your programming language's underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how your language handles numbers that are too large or too small for its underlying representation.
Mitigation MIT-8
Strategy: Input Validation
Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.
Mitigation
Use the appropriate type for the desired action. For example, in C/C++, only use unsigned types for values that could never be negative, such as height, width, or other numbers related to quantity.
Mitigation
Strategy: Language Selection
- Use languages, libraries, or frameworks that make it easier to handle numbers without unexpected consequences.
- Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).
Mitigation
Strategy: Libraries or Frameworks
- Use languages, libraries, or frameworks that make it easier to handle numbers without unexpected consequences.
- Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).
Mitigation MIT-26
Strategy: Compilation or Build Hardening
Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.
CAPEC-128: Integer Attacks
An attacker takes advantage of the structure of integer variables to cause these variables to assume values that are not expected by an application. For example, adding one to the largest positive integer in a signed integer variable results in a negative number. Negative numbers may be illegal in an application and the application may prevent an attacker from providing them directly, but the application may not consider that adding two positive numbers can create a negative number do to the structure of integer storage formats.
CAPEC-129: Pointer Manipulation
This attack pattern involves an adversary manipulating a pointer within a target application resulting in the application accessing an unintended memory location. This can result in the crashing of the application or, for certain pointer values, access to data that would not normally be possible or the execution of arbitrary code. Since pointers are simply integer variables, Integer Attacks may often be used in Pointer Attacks.