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.
300 vulnerabilities reference this CWE, most recent first.
GHSA-2V9V-6H75-597V
Vulnerability from github – Published: 2024-02-28 09:30 – Updated: 2024-12-09 21:31In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix off by one in hdmi_14_process_transaction()
The hdcp_i2c_offsets[] array did not have an entry for HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one read overflow. I added an entry and copied the 0x0 value for the offset from similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c.
I also declared several of these arrays as having HDCP_MESSAGE_ID_MAX entries. This doesn't change the code, but it's just a belt and suspenders approach to try future proof the code.
{
"affected": [],
"aliases": [
"CVE-2021-47046"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-28T09:15:40Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix off by one in hdmi_14_process_transaction()\n\nThe hdcp_i2c_offsets[] array did not have an entry for\nHDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one\nread overflow. I added an entry and copied the 0x0 value for the offset\nfrom similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c.\n\nI also declared several of these arrays as having HDCP_MESSAGE_ID_MAX\nentries. This doesn\u0027t change the code, but it\u0027s just a belt and\nsuspenders approach to try future proof the code.",
"id": "GHSA-2v9v-6h75-597v",
"modified": "2024-12-09T21:31:00Z",
"published": "2024-02-28T09:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47046"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/080bd41d6478a64edf96704fddcda52b1fd5fed7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/403c4528e5887af3deb9838cb77a557631d1e138"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a58310d5d1e5b02d0fc9b393ba540c9367bced5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8e6fafd5a22e7a2eb216f5510db7aab54cc545c1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2WRF-HF7J-CX32
Vulnerability from github – Published: 2022-05-24 17:17 – Updated: 2026-10-09 00:31An off-by-one error in the DecodeBlock function in codec/sdl_image.c in VideoLAN VLC media player before 3.0.9 allows remote attackers to cause a denial of service (memory corruption) via a crafted image file. NOTE: this may be related to the SDL_Image product.
{
"affected": [],
"aliases": [
"CVE-2019-19721"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-05-15T18:15:00Z",
"severity": "MODERATE"
},
"details": "An off-by-one error in the DecodeBlock function in codec/sdl_image.c in VideoLAN VLC media player before 3.0.9 allows remote attackers to cause a denial of service (memory corruption) via a crafted image file. NOTE: this may be related to the SDL_Image product.",
"id": "GHSA-2wrf-hf7j-cx32",
"modified": "2026-10-09T00:31:05Z",
"published": "2022-05-24T17:17:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19721"
},
{
"type": "WEB",
"url": "https://bugs.gentoo.org/721940"
},
{
"type": "WEB",
"url": "https://git.videolan.org/?p=vlc/vlc-3.0.git%3Ba=commit%3Bh=72afe7ebd8305bf4f5360293b8621cde52ec506b"
},
{
"type": "WEB",
"url": "https://git.videolan.org/?p=vlc/vlc-3.0.git;a=commit;h=72afe7ebd8305bf4f5360293b8621cde52ec506b"
},
{
"type": "WEB",
"url": "https://www.videolan.org/security"
},
{
"type": "WEB",
"url": "http://hg.libsdl.org/SDL_image"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-362X-Q9RC-H58C
Vulnerability from github – Published: 2025-10-01 12:30 – Updated: 2026-01-20 18:31In the Linux kernel, the following vulnerability has been resolved:
ext4: fix off-by-one errors in fast-commit block filling
Due to several different off-by-one errors, or perhaps due to a late change in design that wasn't fully reflected in the code that was actually merged, there are several very strange constraints on how fast-commit blocks are filled with tlv entries:
-
tlvs must start at least 10 bytes before the end of the block, even though the minimum tlv length is 8. Otherwise, the replay code will ignore them. (BUG: ext4_fc_reserve_space() could violate this requirement if called with a len of blocksize - 9 or blocksize - 8. Fortunately, this doesn't seem to happen currently.)
-
tlvs must end at least 1 byte before the end of the block. Otherwise the replay code will consider them to be invalid. This quirk contributed to a bug (fixed by an earlier commit) where uninitialized memory was being leaked to disk in the last byte of blocks.
Also, strangely these constraints don't apply to the replay code in e2fsprogs, which will accept any tlvs in the blocks (with no bounds checks at all, but that is a separate issue...).
Given that this all seems to be a bug, let's fix it by just filling blocks with tlv entries in the natural way.
Note that old kernels will be unable to replay fast-commit journals created by kernels that have this commit.
{
"affected": [],
"aliases": [
"CVE-2022-50428"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T12:15:34Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix off-by-one errors in fast-commit block filling\n\nDue to several different off-by-one errors, or perhaps due to a late\nchange in design that wasn\u0027t fully reflected in the code that was\nactually merged, there are several very strange constraints on how\nfast-commit blocks are filled with tlv entries:\n\n- tlvs must start at least 10 bytes before the end of the block, even\n though the minimum tlv length is 8. Otherwise, the replay code will\n ignore them. (BUG: ext4_fc_reserve_space() could violate this\n requirement if called with a len of blocksize - 9 or blocksize - 8.\n Fortunately, this doesn\u0027t seem to happen currently.)\n\n- tlvs must end at least 1 byte before the end of the block. Otherwise\n the replay code will consider them to be invalid. This quirk\n contributed to a bug (fixed by an earlier commit) where uninitialized\n memory was being leaked to disk in the last byte of blocks.\n\nAlso, strangely these constraints don\u0027t apply to the replay code in\ne2fsprogs, which will accept any tlvs in the blocks (with no bounds\nchecks at all, but that is a separate issue...).\n\nGiven that this all seems to be a bug, let\u0027s fix it by just filling\nblocks with tlv entries in the natural way.\n\nNote that old kernels will be unable to replay fast-commit journals\ncreated by kernels that have this commit.",
"id": "GHSA-362x-q9rc-h58c",
"modified": "2026-01-20T18:31:51Z",
"published": "2025-10-01T12:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50428"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18f28f13301d1afb8cea9c4ddcecdbff14488ec6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/48a6a66db82b8043d298a630f22c62d43550cae5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5439ad45c0d0c8db41eb6f4dce6f778f15a5ee16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5ca65dffdead16572ca046c43fb576b227f7f635"
}
],
"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-3763-QP59-59VF
Vulnerability from github – Published: 2026-08-12 15:16 – Updated: 2026-08-12 15:16Impact
The validity store treats a transaction with stored block_number = X as "in window" only when X > last_bn - transaction_validity_window_blocks (strict inequality). However the protocol's Transaction::is_valid_at accepts a transaction for inclusion in any block in [validity_start_height - blocks_per_batch, validity_start_height + window - 1]. By choosing validity_start_height = X + blocks_per_batch (the largest value still compatible with first inclusion at block X), an attacker can replay the same signed transaction in any block B such that X + window < B < validity_start_height + window, i.e., a contiguous window of blocks_per_batch - 1 blocks (59 on MainNet, ~10 minutes) during which the replay-protection check fails to flag it. The same transaction is then executed twice: the sender is debited twice, the recipient credited twice.
Patches
https://github.com/nimiq/core-rs-albatross/pull/3772
Workarounds
No known workarounds
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.5.0"
},
"package": {
"ecosystem": "crates.io",
"name": "nimiq-blockchain"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46369"
],
"database_specific": {
"cwe_ids": [
"CWE-193",
"CWE-294"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-12T15:16:53Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\nThe validity store treats a transaction with stored `block_number = X` as \"in window\" only when `X \u003e last_bn - transaction_validity_window_blocks` (strict inequality). However the protocol\u0027s `Transaction::is_valid_at` accepts a transaction for inclusion in any block in `[validity_start_height - blocks_per_batch, validity_start_height + window - 1]`. By choosing `validity_start_height = X + blocks_per_batch` (the largest value still compatible with first inclusion at block X), an attacker can replay the same signed transaction in any block B such that `X + window \u003c B \u003c validity_start_height + window`, i.e., a contiguous window of `blocks_per_batch - 1` blocks (59 on MainNet, ~10 minutes) during which the replay-protection check fails to flag it. The same transaction is then executed twice: the sender is debited twice, the recipient credited twice.\n\n### Patches\nhttps://github.com/nimiq/core-rs-albatross/pull/3772\n\n### Workarounds\nNo known workarounds",
"id": "GHSA-3763-qp59-59vf",
"modified": "2026-08-12T15:16:53Z",
"published": "2026-08-12T15:16:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nimiq/core-rs-albatross/security/advisories/GHSA-3763-qp59-59vf"
},
{
"type": "WEB",
"url": "https://github.com/nimiq/core-rs-albatross/pull/3772"
},
{
"type": "WEB",
"url": "https://github.com/nimiq/core-rs-albatross/commit/a530b2434ebca6e3716f07c73079786fcc6f2e41"
},
{
"type": "PACKAGE",
"url": "https://github.com/nimiq/core-rs-albatross"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "nimiq-blockchain: Validity store off by one error"
}
GHSA-38W7-MQ68-3H8Q
Vulnerability from github – Published: 2026-07-01 06:31 – Updated: 2026-07-09 06:31UltraVNC viewer through 1.8.2.2 contains an off-by-one stack buffer overflow in the RFB ServerInit message handler. In vncviewer/ClientConnection.cpp, when the server-supplied nameLength equals exactly 2024 the code declares a 2024-byte stack buffer _dn[2024] and calls ReadString(_dn, 2024). ReadString writes the NUL terminator at buf[length], i.e., _dn[2024], one byte past the end of the stack buffer. A malicious VNC server can trigger this condition by advertising a desktop name of length 2024 in its ServerInit message. On release builds without stack canaries the single-byte NUL overwrite adjacent stack data. On builds with /GS stack protection the canary is corrupted and the process terminates, resulting in denial of service. User interaction (connecting the viewer to the malicious server) is required.
{
"affected": [],
"aliases": [
"CVE-2026-7831"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-01T05:16:24Z",
"severity": "HIGH"
},
"details": "UltraVNC viewer through 1.8.2.2 contains an off-by-one stack buffer overflow in the RFB ServerInit message handler. In vncviewer/ClientConnection.cpp, when the server-supplied nameLength equals exactly 2024 the code declares a 2024-byte stack buffer _dn[2024] and calls ReadString(_dn, 2024). ReadString writes the NUL terminator at buf[length], i.e., _dn[2024], one byte past the end of the stack buffer. A malicious VNC server can trigger this condition by advertising a desktop name of length 2024 in its ServerInit message. On release builds without stack canaries the single-byte NUL overwrite adjacent stack data. On builds with /GS stack protection the canary is corrupted and the process terminates, resulting in denial of service. User interaction (connecting the viewer to the malicious server) is required.",
"id": "GHSA-38w7-mq68-3h8q",
"modified": "2026-07-09T06:31:59Z",
"published": "2026-07-01T06:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7831"
},
{
"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-7831-off-by-one-stack-overflow-viewer-namelength-ultravnc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3CM8-8GXQ-6JR4
Vulnerability from github – Published: 2022-06-16 00:00 – Updated: 2025-01-02 21:31Windows Kernel Denial of Service Vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-30155"
],
"database_specific": {
"cwe_ids": [
"CWE-193",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-15T22:15:00Z",
"severity": "MODERATE"
},
"details": "Windows Kernel Denial of Service Vulnerability.",
"id": "GHSA-3cm8-8gxq-6jr4",
"modified": "2025-01-02T21:31:38Z",
"published": "2022-06-16T00:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30155"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-30155"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-30155"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/167755/Windows-Kernel-nt-MiRelocateImage-Invalid-Read.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3P24-8MW5-X2HX
Vulnerability from github – Published: 2025-07-04 15:31 – Updated: 2025-11-03 21:34Mbed TLS before 3.6.4 has a PEM parsing one-byte heap-based buffer underflow, in mbedtls_pem_read_buffer and two mbedtls_pk_parse functions, via untrusted PEM input.
{
"affected": [],
"aliases": [
"CVE-2025-52497"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-04T15:15:22Z",
"severity": "MODERATE"
},
"details": "Mbed TLS before 3.6.4 has a PEM parsing one-byte heap-based buffer underflow, in mbedtls_pem_read_buffer and two mbedtls_pk_parse functions, via untrusted PEM input.",
"id": "GHSA-3p24-8mw5-x2hx",
"modified": "2025-11-03T21:34:05Z",
"published": "2025-07-04T15:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52497"
},
{
"type": "WEB",
"url": "https://github.com/Mbed-TLS/mbedtls-docs/blob/main/security-advisories/mbedtls-security-advisory-2025-06-2.md"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00013.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-3QGV-JW3W-GQ48
Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2022-05-13 01:53An issue was discovered in Botan 1.11.32 through 2.x before 2.6.0. An off-by-one error when processing malformed TLS-CBC ciphertext could cause the receiving side to include in the HMAC computation exactly 64K bytes of data following the record buffer, aka an over-read. The MAC comparison will subsequently fail and the connection will be closed. This could be used for denial of service. No information leak occurs.
{
"affected": [],
"aliases": [
"CVE-2018-9860"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-12T05:29:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Botan 1.11.32 through 2.x before 2.6.0. An off-by-one error when processing malformed TLS-CBC ciphertext could cause the receiving side to include in the HMAC computation exactly 64K bytes of data following the record buffer, aka an over-read. The MAC comparison will subsequently fail and the connection will be closed. This could be used for denial of service. No information leak occurs.",
"id": "GHSA-3qgv-jw3w-gq48",
"modified": "2022-05-13T01:53:57Z",
"published": "2022-05-13T01:53:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9860"
},
{
"type": "WEB",
"url": "https://botan.randombit.net/security.html"
},
{
"type": "WEB",
"url": "https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7434"
}
],
"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"
}
]
}
GHSA-3W55-CQRX-X67W
Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-16 15:30arduino-TuyaOpen before version 1.2.1 contains a single-byte buffer overflow vulnerability in the WiFiMulti component. When the victim's smart hardware connects to an attacker-controlled AP hotspot, the attacker can exploit the overflow to execute arbitrary code on the affected embedded device.
{
"affected": [],
"aliases": [
"CVE-2026-28520"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-16T14:19:28Z",
"severity": "HIGH"
},
"details": "arduino-TuyaOpen before version 1.2.1 contains a single-byte buffer overflow vulnerability in the WiFiMulti component. When the victim\u0027s smart hardware connects to an attacker-controlled AP hotspot, the attacker can exploit the overflow to execute arbitrary code on the affected embedded device.",
"id": "GHSA-3w55-cqrx-x67w",
"modified": "2026-03-16T15:30:42Z",
"published": "2026-03-16T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28520"
},
{
"type": "WEB",
"url": "https://github.com/tuya/arduino-TuyaOpen"
},
{
"type": "WEB",
"url": "https://src.tuya.com/announcement/32"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/arduino-tuyaopen-wifimulti-single-byte-buffer-overflow-remote-code-execution"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/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-3XJW-75CJ-9FVW
Vulnerability from github – Published: 2025-04-18 15:31 – Updated: 2025-04-29 18:30In the Linux kernel, the following vulnerability has been resolved:
LoongArch: BPF: Fix off-by-one error in build_prologue()
Vincent reported that running BPF progs with tailcalls on LoongArch causes kernel hard lockup. Debugging the issues shows that the JITed image missing a jirl instruction at the end of the epilogue.
There are two passes in JIT compiling, the first pass set the flags and the second pass generates JIT code based on those flags. With BPF progs mixing bpf2bpf and tailcalls, build_prologue() generates N insns in the first pass and then generates N+1 insns in the second pass. This makes epilogue_offset off by one and we will jump to some unexpected insn and cause lockup. Fix this by inserting a nop insn.
{
"affected": [],
"aliases": [
"CVE-2025-37893"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-18T07:15:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: BPF: Fix off-by-one error in build_prologue()\n\nVincent reported that running BPF progs with tailcalls on LoongArch\ncauses kernel hard lockup. Debugging the issues shows that the JITed\nimage missing a jirl instruction at the end of the epilogue.\n\nThere are two passes in JIT compiling, the first pass set the flags and\nthe second pass generates JIT code based on those flags. With BPF progs\nmixing bpf2bpf and tailcalls, build_prologue() generates N insns in the\nfirst pass and then generates N+1 insns in the second pass. This makes\nepilogue_offset off by one and we will jump to some unexpected insn and\ncause lockup. Fix this by inserting a nop insn.",
"id": "GHSA-3xjw-75cj-9fvw",
"modified": "2025-04-29T18:30:52Z",
"published": "2025-04-18T15:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37893"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/205a2182c51ffebaef54d643e3745e720cded08b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/48b904de2408af5f936f0e03f48dfcddeab58aa0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e2586991e36663c9bc48c828b83eab180ad30a9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3ffad2f02db4aace6799fe0049508b8925eae45"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c74d95a5679741ef428974ab788f5b0758dc78ae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e9ccb262b39ab01a5ac2e485b7996b8498e7b373"
}
],
"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"
}
]
}
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.