CWE-193
AllowedOff-by-one Error
Abstraction: Base · Status: Draft
A product calculates or uses an incorrect maximum or minimum value that is 1 more, or 1 less, than the correct value.
256 vulnerabilities reference this CWE, most recent first.
GHSA-FJ2P-R342-GX3M
Vulnerability from github – Published: 2022-05-02 00:05 – Updated: 2022-05-02 00:05Multiple off-by-one errors in libpng before 1.2.32beta01, and 1.4 before 1.4.0beta34, allow context-dependent attackers to cause a denial of service (crash) or have unspecified other impact via a PNG image with crafted zTXt chunks, related to (1) the png_push_read_zTXt function in pngread.c, and possibly related to (2) pngtest.c.
{
"affected": [],
"aliases": [
"CVE-2008-3964"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-09-11T01:13:00Z",
"severity": "MODERATE"
},
"details": "Multiple off-by-one errors in libpng before 1.2.32beta01, and 1.4 before 1.4.0beta34, allow context-dependent attackers to cause a denial of service (crash) or have unspecified other impact via a PNG image with crafted zTXt chunks, related to (1) the png_push_read_zTXt function in pngread.c, and possibly related to (2) pngtest.c.",
"id": "GHSA-fj2p-r342-gx3m",
"modified": "2022-05-02T00:05:25Z",
"published": "2022-05-02T00:05:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-3964"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/44928"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/31781"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/33137"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35302"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35386"
},
{
"type": "WEB",
"url": "http://security.gentoo.org/glsa/glsa-200812-15.xml"
},
{
"type": "WEB",
"url": "http://sourceforge.net/mailarchive/forum.php?thread_name=e56ccc8f0809180317u6a5306fg14683947affb3e1b%40mail.gmail.com\u0026forum_name=png-mng-implement"
},
{
"type": "WEB",
"url": "http://sourceforge.net/project/shownotes.php?group_id=5624\u0026release_id=624517"
},
{
"type": "WEB",
"url": "http://sourceforge.net/project/shownotes.php?release_id=624518"
},
{
"type": "WEB",
"url": "http://sourceforge.net/tracker/index.php?func=detail\u0026aid=2095669\u0026group_id=5624\u0026atid=105624"
},
{
"type": "WEB",
"url": "http://sunsolve.sun.com/search/document.do?assetkey=1-66-259989-1"
},
{
"type": "WEB",
"url": "http://sunsolve.sun.com/search/document.do?assetkey=1-77-1020521.1-1"
},
{
"type": "WEB",
"url": "http://support.avaya.com/elmodocs2/security/ASA-2009-208.htm"
},
{
"type": "WEB",
"url": "http://www.kb.cert.org/vuls/id/889484"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDVSA-2009:051"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2008/09/09/3"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2008/09/09/8"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/31049"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2008/2512"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/1462"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/1560"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FPPM-3X24-27Q8
Vulnerability from github – Published: 2022-04-30 18:16 – Updated: 2024-02-15 21:31Format string vulnerability in Infodrom cfingerd 1.4.3 and earlier allows a remote attacker to gain additional privileges via a malformed ident reply that is passed to the syslog function.
{
"affected": [],
"aliases": [
"CVE-2001-0609"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2001-08-02T04:00:00Z",
"severity": "HIGH"
},
"details": "Format string vulnerability in Infodrom cfingerd 1.4.3 and earlier allows a remote attacker to gain additional privileges via a malformed ident reply that is passed to the syslog function.",
"id": "GHSA-fppm-3x24-27q8",
"modified": "2024-02-15T21:31:21Z",
"published": "2022-04-30T18:16:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2001-0609"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/6364"
},
{
"type": "WEB",
"url": "http://archives.neohapsis.com/archives/bugtraq/2001-04/0202.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/2576"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FQ9X-8G2W-4P5R
Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-07-08 06:31In the Linux kernel, the following vulnerability has been resolved:
6lowpan: fix off-by-one in multicast context address compression
The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively.
This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents
The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID)
Also zero-initialize the data array as a defensive measure against similar bugs in the future.
{
"affected": [],
"aliases": [
"CVE-2026-53263"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T09:16:44Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\n6lowpan: fix off-by-one in multicast context address compression\n\nThe second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses\n\u0026data[1] as destination and \u0026ipaddr-\u003es6_addr[11] as source, but\nboth should be offset by one: \u0026data[2] and \u0026ipaddr-\u003es6_addr[12]\nrespectively.\n\nThis off-by-one has two consequences:\n1. data[1] is overwritten with s6_addr[11], corrupting the RIID\n field in the compressed multicast address\n2. data[5] is never written, so uninitialized kernel stack memory\n is transmitted over the network via lowpan_push_hc_data(),\n leaking kernel stack contents\n\nThe correct inline data layout must match what the decompression\nfunction lowpan_uncompress_multicast_ctx_daddr() expects:\n data[0..1] = s6_addr[1..2] (flags/scope + RIID)\n data[2..5] = s6_addr[12..15] (group ID)\n\nAlso zero-initialize the data array as a defensive measure against\nsimilar bugs in the future.",
"id": "GHSA-fq9x-8g2w-4p5r",
"modified": "2026-07-08T06:31:34Z",
"published": "2026-06-25T09:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53263"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/06ce6fc106b16dec9b535950db626261be865e5b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a58899d11009bffc7b4b32a571858f381121837"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4485d79617520d84ba5a14515e2b5136007d6deb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c32f30ef5e66adbfa102348e2e8a23776eb007cb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/da8808463882c3f3c357b072e25053c2121f1419"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/da8cbb64b47e9066b40af0de170901caf17b768c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dcb1bec1c32ee5c3878354e087cf5dbee2b7c7af"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f24a58c72a45f4c109f3557a760cc4b60b7a6037"
}
],
"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-GH7J-9W79-XM55
Vulnerability from github – Published: 2026-07-01 06:31 – Updated: 2026-07-09 06:31UltraVNC repeater through 1.8.2.2 contains an off-by-one error in the Base64 decode helper used for HTTP Basic authentication. In repeater/webgui/webutils.c:817, the wi_uudecode() function checks whether the input length exceeds the output buffer with a strict greater-than comparison (>), while the correct check should be greater-than-or-equal (>=). When strlen(authdata) equals sizeof(decode), the decoded output length (approximately 3/4 of input) does not overflow the buffer in current practice because the outer HTTP request bounds constrain the Authorization header. However, the defective check leaves a latent off-by-one condition that could become exploitable if the buffering constraints change. The current risk is limited to a one-byte write at the boundary of a 1024-byte stack buffer under constrained conditions.
{
"affected": [],
"aliases": [
"CVE-2026-44042"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-01T05:16:21Z",
"severity": "LOW"
},
"details": "UltraVNC repeater through 1.8.2.2 contains an off-by-one error in the Base64 decode helper used for HTTP Basic authentication. In repeater/webgui/webutils.c:817, the wi_uudecode() function checks whether the input length exceeds the output buffer with a strict greater-than comparison (\u003e), while the correct check should be greater-than-or-equal (\u003e=). When strlen(authdata) equals sizeof(decode), the decoded output length (approximately 3/4 of input) does not overflow the buffer in current practice because the outer HTTP request bounds constrain the Authorization header. However, the defective check leaves a latent off-by-one condition that could become exploitable if the buffering constraints change. The current risk is limited to a one-byte write at the boundary of a 1024-byte stack buffer under constrained conditions.",
"id": "GHSA-gh7j-9w79-xm55",
"modified": "2026-07-09T06:31:59Z",
"published": "2026-07-01T06:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44042"
},
{
"type": "WEB",
"url": "https://github.com/ultravnc/UltraVNC"
},
{
"type": "WEB",
"url": "https://uvnc.com"
},
{
"type": "WEB",
"url": "https://www.securin.io/zero-days/cve-2026-44042-wi-uudecode-off-by-one-bounded-ultravnc-repeater"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-GJQW-R32J-J6WQ
Vulnerability from github – Published: 2022-05-24 17:49 – Updated: 2024-03-21 03:34In mjs_json.c in Cesanta MongooseOS mJS 1.26, a maliciously formed JSON string can trigger an off-by-one heap-based buffer overflow in mjs_json_parse, which can potentially lead to redirection of control flow.
{
"affected": [],
"aliases": [
"CVE-2021-31875"
],
"database_specific": {
"cwe_ids": [
"CWE-193",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-29T02:15:00Z",
"severity": "CRITICAL"
},
"details": "In mjs_json.c in Cesanta MongooseOS mJS 1.26, a maliciously formed JSON string can trigger an off-by-one heap-based buffer overflow in mjs_json_parse, which can potentially lead to redirection of control flow.",
"id": "GHSA-gjqw-r32j-j6wq",
"modified": "2024-03-21T03:34:04Z",
"published": "2022-05-24T17:49:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31875"
},
{
"type": "WEB",
"url": "https://github.com/418sec/mjs/pull/2"
},
{
"type": "WEB",
"url": "https://github.com/cesanta/mjs/releases/tag/1.26"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/1-other-mjs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GMQ8-994R-JV83
Vulnerability from github – Published: 2026-03-12 00:31 – Updated: 2026-03-16 12:35yauzl (aka Yet Another Unzip Library) version 3.2.0 for Node.js contains an off-by-one error in the NTFS extended timestamp extra field parser within the getLastModDate() function. The while loop condition checks cursor < data.length + 4 instead of cursor + 4 <= data.length, allowing readUInt16LE() to read past the buffer boundary. A remote attacker can cause a denial of service (process crash via ERR_OUT_OF_RANGE exception) by sending a crafted zip file with a malformed NTFS extra field. This affects any Node.js application that processes zip file uploads and calls entry.getLastModDate() on parsed entries. Fixed in version 3.2.1.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "yauzl"
},
"ranges": [
{
"events": [
{
"introduced": "3.2.0"
},
{
"fixed": "3.2.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"3.2.0"
]
}
],
"aliases": [
"CVE-2026-31988"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-13T18:58:11Z",
"nvd_published_at": "2026-03-11T23:16:00Z",
"severity": "MODERATE"
},
"details": "yauzl (aka Yet Another Unzip Library) version 3.2.0 for Node.js contains an off-by-one error in the NTFS extended timestamp extra field parser within the getLastModDate() function. The while loop condition checks cursor \u003c data.length + 4 instead of cursor + 4 \u003c= data.length, allowing readUInt16LE() to read past the buffer boundary. A remote attacker can cause a denial of service (process crash via ERR_OUT_OF_RANGE exception) by sending a crafted zip file with a malformed NTFS extra field. This affects any Node.js application that processes zip file uploads and calls entry.getLastModDate() on parsed entries. Fixed in version 3.2.1.",
"id": "GHSA-gmq8-994r-jv83",
"modified": "2026-03-16T12:35:31Z",
"published": "2026-03-12T00:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31988"
},
{
"type": "WEB",
"url": "https://github.com/thejoshwolfe/yauzl/commit/c4695215b05c6adffda613b9051a2a85429b33fe"
},
{
"type": "PACKAGE",
"url": "https://github.com/thejoshwolfe/yauzl"
},
{
"type": "WEB",
"url": "https://www.codeant.ai/security-research/yauzl-denial-of-service-zip-file-crash"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/package/yauzl"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/yauzl-denial-of-service-via-off-by-one-error-in-ntfs-timestamp-parser"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "yauzl contains an off-by-one error"
}
GHSA-GW5P-Q8MJ-P7GH
Vulnerability from github – Published: 2023-09-14 19:33 – Updated: 2025-05-02 12:53Impact
Wasmtime versions from 10.0.0 to 12.0.1 contain a miscompilation of the WebAssembly i64x2.shr_s instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the i64x2.shr_s with a constant shift amount larger than 32 may produce an incorrect result.
This issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless.
This issue was discovered through fuzzing of Wasmtime's code generator Cranelift.
Patches
Wasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation.
Workarounds
This issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to disable the SIMD proposal for WebAssembly. Users prior to 10.0.0 are unaffected by this vulnerability.
References
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-41880"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-14T19:33:17Z",
"nvd_published_at": "2023-09-15T20:15:11Z",
"severity": "LOW"
},
"details": "### Impact\n\nWasmtime versions from 10.0.0 to 12.0.1 contain a miscompilation of the WebAssembly `i64x2.shr_s` instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the `i64x2.shr_s` with a constant shift amount larger than 32 may produce an incorrect result.\n\nThis issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless.\n\nThis issue was discovered through fuzzing of Wasmtime\u0027s code generator Cranelift.\n\n### Patches\n\nWasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation.\n\n### Workarounds\n\nThis issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to [disable the SIMD proposal for WebAssembly](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd). Users prior to 10.0.0 are unaffected by this vulnerability.\n\n### References\n\n* [PR which introduced this bug to Wasmtime](https://github.com/bytecodealliance/wasmtime/pull/6372)\n* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/B8PJgg6bEdg)",
"id": "GHSA-gw5p-q8mj-p7gh",
"modified": "2025-05-02T12:53:12Z",
"published": "2023-09-14T19:33:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-gw5p-q8mj-p7gh"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-gw5p-q8mj-p7gh#:~:text=Mailing%20list%20announcement"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41880"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/pull/6372"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/commit/8d7eda15b0badcbea83a7aac2d08f80788b59240"
},
{
"type": "WEB",
"url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd"
},
{
"type": "PACKAGE",
"url": "https://github.com/bytecodealliance/wasmtime"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2023-0091.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Miscompilation of wasm `i64x2.shr_s` instruction with constant input on x86_64"
}
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-H835-4P8W-83C9
Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14UltraVNC revision 1206 has multiple off-by-one vulnerabilities in VNC client code connected with improper usage of ClientConnection::ReadString function, which can potentially result code execution. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1207.
{
"affected": [],
"aliases": [
"CVE-2019-8268"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-03-08T23:29:00Z",
"severity": "CRITICAL"
},
"details": "UltraVNC revision 1206 has multiple off-by-one vulnerabilities in VNC client code connected with improper usage of ClientConnection::ReadString function, which can potentially result code execution. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1207.",
"id": "GHSA-h835-4p8w-83c9",
"modified": "2022-05-13T01:14:29Z",
"published": "2022-05-13T01:14:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8268"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-927095.pdf"
},
{
"type": "WEB",
"url": "https://ics-cert.kaspersky.com/advisories/klcert-advisories/2019/03/01/klcert-19-015-ultravnc-off-by-one-error"
},
{
"type": "WEB",
"url": "https://www.us-cert.gov/ics/advisories/icsa-20-161-06"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H88Q-M8MM-7243
Vulnerability from github – Published: 2026-06-30 15:30 – Updated: 2026-06-30 15:30A flaw was found in GLib. An off-by-one error can occur in the g_key_file_get_locale_string_list function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.
{
"affected": [],
"aliases": [
"CVE-2026-58014"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T13:19:17Z",
"severity": "HIGH"
},
"details": "A flaw was found in GLib. An off-by-one error can occur in the g_key_file_get_locale_string_list function in the gkeyfile.c file when loading a key file with an empty value. This flaw can cause an out-of-bounds access of 1 byte or a denial of service when the out-of-bounds access crosses a page boundary.",
"id": "GHSA-h88q-m8mm-7243",
"modified": "2026-06-30T15:30:45Z",
"published": "2026-06-30T15:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58014"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-58014"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492255"
},
{
"type": "WEB",
"url": "https://gitlab.gnome.org/GNOME/glib/-/issues/3930"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
Mitigation
When copying character arrays or using character manipulation methods, the correct size parameter must be used to account for the null terminator that needs to be added at the end of the array. Some examples of functions susceptible to this weakness in C include strcpy(), strncpy(), strcat(), strncat(), printf(), sprintf(), scanf() and sscanf().
No CAPEC attack patterns related to this CWE.