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.
159 vulnerabilities reference this CWE, most recent first.
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"
}
]
}
GHSA-HCW3-J74M-QC58
Vulnerability from github – Published: 2022-02-09 22:17 – Updated: 2024-05-20 20:41Impact
Under certain conditions, pretty-printing an AST that contains synthetic nodes could change the logic of some statements by reordering array literals. Example of policies impacted are those that parse and compare web paths, see the example below.
All of these three conditions have to be met to create an adverse effect:
- An AST of Rego had to be created programmatically such that it ends up containing terms without a location (such as wildcard variables).
- The AST had to be pretty-printed using the
github.com/open-policy-agent/opa/formatpackage. - The result of the pretty-printing had to be parsed and evaluated again via an OPA instance using the bundles, or the Golang packages.
If any of these three conditions are not met, you are not affected.
Notably, all three would be true if using optimized bundles, i.e. bundles created with opa build -O=1 or higher.
In that case, the optimizer would fulfil condition (1.), the result of that would be pretty-printed when writing the bundle to disk, fulfilling (2.). When the bundle was then used, we'd satisfy (3.).
Example
For example, the process outlined above could turn this rule
hello {
["foo", _] = split(input.resource, "/")
}
into
hello {
[_, "foo"] = split(input.resource, "/")
}
with an input of
{
"resource": "foo/bar"
}
the result would change from
{
"hello": true
}
to (no default value of hello)
{}
The severity was determined to be moderate because the conditions are quite particular. Please note that its only the OPA bundle build process thats affected. An OPA sidecar of version 0.36.0 with an optimized bundle built by OPA 0.32.1 would not face this bug.
Patches
Fixed in version 0.37.2.
Workarounds
- Disabling optimization when creating bundles.
References
- Introduced in https://github.com/open-policy-agent/opa/pull/3851
- Backported for the 0.33.1 patch release: https://github.com/open-policy-agent/opa/commit/bfd984ddf93ef2c4963a08d4fdadae0bcf1a3717
- Fixed by https://github.com/open-policy-agent/opa/commit/932e4ffc37a590ace79e9b75ca4340288c220239 and https://github.com/open-policy-agent/opa/commit/2bd8edab9e10e2dc9cf76ae8335ced0c224f3055
For more information
If you have any questions or comments about this advisory:
- Open an issue in Community Discussions
- Ask in Slack: https://slack.openpolicyagent.org/
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/open-policy-agent/opa"
},
"ranges": [
{
"events": [
{
"introduced": "0.33.1"
},
{
"fixed": "0.37.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-23628"
],
"database_specific": {
"cwe_ids": [
"CWE-682"
],
"github_reviewed": true,
"github_reviewed_at": "2022-02-09T22:17:37Z",
"nvd_published_at": "2022-02-09T22:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nUnder certain conditions, pretty-printing an AST that contains synthetic nodes could change the logic of some statements by reordering array literals. Example of policies impacted are those that parse and compare web paths, see the example below.\n\n**All of these** three conditions have to be met to create an adverse effect:\n\n1. An AST of Rego had to be **created programmatically** such that it ends up containing terms without a location (such as wildcard variables).\n2. The AST had to be **pretty-printed** using the `github.com/open-policy-agent/opa/format` package.\n3. The result of the pretty-printing had to be **parsed and evaluated again** via an OPA instance using the bundles, or the Golang packages.\n\nIf any of these three conditions are not met, you are not affected.\n\nNotably, all three would be true if using **optimized bundles**, i.e. bundles created with `opa build -O=1` or higher.\nIn that case, the optimizer would fulfil condition (1.), the result of that would be pretty-printed when writing the bundle to disk, fulfilling (2.). When the bundle was then used, we\u0027d satisfy (3.).\n\n#### Example\nFor example, the process outlined above could turn \nthis rule\n```rego\nhello {\n\t[\"foo\", _] = split(input.resource, \"/\")\n}\n```\n\ninto\n```rego\nhello {\n\t[_, \"foo\"] = split(input.resource, \"/\")\n}\n```\n\nwith an input of\n```rego\n{\n \"resource\": \"foo/bar\"\n}\n```\n\nthe result would change from\n```rego\n{\n \"hello\": true\n}\n```\nto (no default value of hello)\n```rego\n{}\n```\n\nThe severity was determined to be *moderate* because the conditions are quite particular. Please note that its only the OPA bundle build process thats affected. An OPA sidecar of version 0.36.0 with an optimized bundle built by OPA 0.32.1 would not face this bug.\n\n### Patches\n\nFixed in version 0.37.2.\n\n### Workarounds\n\n- Disabling optimization when creating bundles.\n\n### References\n\n- Introduced in https://github.com/open-policy-agent/opa/pull/3851\n- Backported for the 0.33.1 patch release: https://github.com/open-policy-agent/opa/commit/bfd984ddf93ef2c4963a08d4fdadae0bcf1a3717\n- Fixed by https://github.com/open-policy-agent/opa/commit/932e4ffc37a590ace79e9b75ca4340288c220239 and https://github.com/open-policy-agent/opa/commit/2bd8edab9e10e2dc9cf76ae8335ced0c224f3055\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [Community Discussions](https://github.com/open-policy-agent/community/discussions/categories/opa-and-rego)\n* Ask in Slack: https://slack.openpolicyagent.org/",
"id": "GHSA-hcw3-j74m-qc58",
"modified": "2024-05-20T20:41:41Z",
"published": "2022-02-09T22:17:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-policy-agent/opa/security/advisories/GHSA-hcw3-j74m-qc58"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23628"
},
{
"type": "WEB",
"url": "https://github.com/open-policy-agent/opa/pull/3851"
},
{
"type": "WEB",
"url": "https://github.com/open-policy-agent/opa/commit/2bd8edab9e10e2dc9cf76ae8335ced0c224f3055"
},
{
"type": "WEB",
"url": "https://github.com/open-policy-agent/opa/commit/932e4ffc37a590ace79e9b75ca4340288c220239"
},
{
"type": "WEB",
"url": "https://github.com/open-policy-agent/opa/commit/bfd984ddf93ef2c4963a08d4fdadae0bcf1a3717"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-policy-agent/opa"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2022-0316"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Incorrect Calculation in github.com/open-policy-agent/opa"
}
GHSA-HH7C-JPM3-846Q
Vulnerability from github – Published: 2022-04-16 00:00 – Updated: 2022-04-23 00:03STB v2.27 was discovered to contain an integer shift of invalid size in the component stbi__jpeg_decode_block_prog_ac.
{
"affected": [],
"aliases": [
"CVE-2022-28048"
],
"database_specific": {
"cwe_ids": [
"CWE-682"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-15T14:15:00Z",
"severity": "HIGH"
},
"details": "STB v2.27 was discovered to contain an integer shift of invalid size in the component stbi__jpeg_decode_block_prog_ac.",
"id": "GHSA-hh7c-jpm3-846q",
"modified": "2022-04-23T00:03:21Z",
"published": "2022-04-16T00:00:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28048"
},
{
"type": "WEB",
"url": "https://github.com/nothings/stb/issues/1293"
},
{
"type": "WEB",
"url": "https://github.com/nothings/stb/pull/1297"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5FXLM5XL77SNH4IPTSXOQD7XL4E2EMIN"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/I4HXIWU5HBOADXZVMREHT4YTO5WVYXEQ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MMBCMJGAZRQS55SNECUWZSC5URVLEZ5R"
}
],
"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-HHWH-Q2MG-R3CP
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-- calculation.
{
"affected": [],
"aliases": [
"CVE-2021-44491"
],
"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-- calculation.",
"id": "GHSA-hhwh-q2mg-r3cp",
"modified": "2022-04-23T00:03:15Z",
"published": "2022-04-16T00:00:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44491"
},
{
"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"
}
]
}
GHSA-HJWV-27QH-X9J5
Vulnerability from github – Published: 2022-01-26 00:00 – Updated: 2022-02-02 00:02On certain hardware BIG-IP platforms, in version 15.1.x before 15.1.4 and 14.1.x before 14.1.3, virtual servers may stop responding while processing TCP traffic due to an issue in the SYN Cookie Protection feature. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
{
"affected": [],
"aliases": [
"CVE-2022-23011"
],
"database_specific": {
"cwe_ids": [
"CWE-682"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-25T20:15:00Z",
"severity": "HIGH"
},
"details": "On certain hardware BIG-IP platforms, in version 15.1.x before 15.1.4 and 14.1.x before 14.1.3, virtual servers may stop responding while processing TCP traffic due to an issue in the SYN Cookie Protection feature. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
"id": "GHSA-hjwv-27qh-x9j5",
"modified": "2022-02-02T00:02:02Z",
"published": "2022-01-26T00:00:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23011"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K68755210"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HMVX-MW63-JVG7
Vulnerability from github – Published: 2024-07-30 09:32 – Updated: 2024-07-30 21:31In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: fix calc_available_free_space() for zoned mode
calc_available_free_space() returns the total size of metadata (or system) block groups, which can be allocated from unallocated disk space. The logic is wrong on zoned mode in two places.
First, the calculation of data_chunk_size is wrong. We always allocate one zone as one chunk, and no partial allocation of a zone. So, we should use zone_size (= data_sinfo->chunk_size) as it is.
Second, the result "avail" may not be zone aligned. Since we always allocate one zone as one chunk on zoned mode, returning non-zone size aligned bytes will result in less pressure on the async metadata reclaim process.
This is serious for the nearly full state with a large zone size device. Allowing over-commit too much will result in less async reclaim work and end up in ENOSPC. We can align down to the zone size to avoid that.
{
"affected": [],
"aliases": [
"CVE-2024-42231"
],
"database_specific": {
"cwe_ids": [
"CWE-682"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-30T08:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: fix calc_available_free_space() for zoned mode\n\ncalc_available_free_space() returns the total size of metadata (or\nsystem) block groups, which can be allocated from unallocated disk\nspace. The logic is wrong on zoned mode in two places.\n\nFirst, the calculation of data_chunk_size is wrong. We always allocate\none zone as one chunk, and no partial allocation of a zone. So, we\nshould use zone_size (= data_sinfo-\u003echunk_size) as it is.\n\nSecond, the result \"avail\" may not be zone aligned. Since we always\nallocate one zone as one chunk on zoned mode, returning non-zone size\naligned bytes will result in less pressure on the async metadata reclaim\nprocess.\n\nThis is serious for the nearly full state with a large zone size device.\nAllowing over-commit too much will result in less async reclaim work and\nend up in ENOSPC. We can align down to the zone size to avoid that.",
"id": "GHSA-hmvx-mw63-jvg7",
"modified": "2024-07-30T21:31:27Z",
"published": "2024-07-30T09:32:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42231"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64d2c847ba380e07b9072d65a50aa6469d2aa43f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8548903b1999bba02a2b894ad750ab8eb1f40307"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HPW2-J46J-HPV2
Vulnerability from github – Published: 2022-05-13 01:36 – Updated: 2022-05-13 01:36A flaw was found in the Linux kernel's handling of clearing SELinux attributes on /proc/pid/attr files before 4.9.10. An empty (null) write to this file can crash the system by causing the system to attempt to access unmapped kernel memory.
{
"affected": [],
"aliases": [
"CVE-2017-2618"
],
"database_specific": {
"cwe_ids": [
"CWE-193",
"CWE-682"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-27T19:29:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in the Linux kernel\u0027s handling of clearing SELinux attributes on /proc/pid/attr files before 4.9.10. An empty (null) write to this file can crash the system by causing the system to attempt to access unmapped kernel memory.",
"id": "GHSA-hpw2-j46j-hpv2",
"modified": "2022-05-13T01:36:53Z",
"published": "2022-05-13T01:36:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2618"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:0931"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:0932"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:0933"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2017-2618"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1419916"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2618"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0c461cb727d146c9ef2d3e86214f498b78b7d125"
},
{
"type": "WEB",
"url": "https://marc.info/?l=selinux\u0026m=148588165923772\u0026w=2"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2017/dsa-3791"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/96272"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/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.