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.
279 vulnerabilities reference this CWE, most recent first.
GHSA-25CM-2563-466G
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:31In the Linux kernel, the following vulnerability has been resolved:
net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring
When an sk_msg scatterlist ring wraps (sg.end < sg.start), tls_push_record() chains the tail portion of the ring to the head using sg_chain(). An extra entry in the sg array is reserved for this:
struct sk_msg_sg { [...] / The extra two elements: * 1) used for chaining the front and sections when the list becomes * partitioned (e.g. end < start). The crypto APIs require the * chaining; * 2) to chain tailer SG entries after the message. / struct scatterlist data[MAX_MSG_FRAGS + 2];
The current code uses MAX_SKB_FRAGS + 1 as the ring size:
sg_chain(&msg_pl->sg.data[msg_pl->sg.start],
MAX_SKB_FRAGS - msg_pl->sg.start + 1,
msg_pl->sg.data);
This places the chain pointer at
sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. = &data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 = data[start + (MAX_SKB_FRAGS - start + 1) - 1] = data[MAX_SKB_FRAGS]
instead of the true last entry. This is likely due to a "race" of the commit under Fixes landing close to commit 031097d9e079 ("bpf: sk_msg, zap ingress queue on psock down")
Convert to ARRAY_SIZE and drop the data[start] / - start (as suggested by Sabrina).
{
"affected": [],
"aliases": [
"CVE-2026-64047"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:45Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring\n\nWhen an sk_msg scatterlist ring wraps (sg.end \u003c sg.start),\ntls_push_record() chains the tail portion of the ring to the head\nusing sg_chain(). An extra entry in the sg array is reserved for\nthis:\n\n struct sk_msg_sg {\n [...]\n /* The extra two elements:\n * 1) used for chaining the front and sections when the list becomes\n * partitioned (e.g. end \u003c start). The crypto APIs require the\n * chaining;\n * 2) to chain tailer SG entries after the message.\n */\n struct scatterlist data[MAX_MSG_FRAGS + 2];\n\nThe current code uses MAX_SKB_FRAGS + 1 as the ring size:\n\n sg_chain(\u0026msg_pl-\u003esg.data[msg_pl-\u003esg.start],\n MAX_SKB_FRAGS - msg_pl-\u003esg.start + 1,\n msg_pl-\u003esg.data);\n\nThis places the chain pointer at\n\n sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. =\n \u0026data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 =\n data[start + (MAX_SKB_FRAGS - start + 1) - 1] =\n data[MAX_SKB_FRAGS]\n\ninstead of the true last entry. This is likely due to a \"race\" of\nthe commit under Fixes landing close to\ncommit 031097d9e079 (\"bpf: sk_msg, zap ingress queue on psock down\")\n\nConvert to ARRAY_SIZE and drop the data[start] / - start (as suggested\nby Sabrina).",
"id": "GHSA-25cm-2563-466g",
"modified": "2026-07-20T15:31:57Z",
"published": "2026-07-19T18:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64047"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/131ef12057d92b77b636321b7849c69222405a97"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/285943c6e7ca309bbea84b253745154241d9788a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2fb0dc7e0099686c4e9d2732745d8a31b18c3628"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/47110c3a9ac247b688657337f5981efcfcb240dc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/66339b71f105e6f83e0da3b9583d95077534fe1d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/73963a375885d5ccb7def39fd0b4f542e0f343dd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84158c2997159df4a0d70cd9c46774512d32a522"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eca989eab4b2599dcb02f72140a7c08f08838520"
}
],
"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-294M-6544-VPRQ
Vulnerability from github – Published: 2024-05-03 15:30 – Updated: 2024-06-03 18:53In the Linux kernel, the following vulnerability has been resolved:
of: fdt: fix off-by-one error in unflatten_dt_nodes()
Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree") forgot to fix up the depth check in the loop body in unflatten_dt_nodes() which makes it possible to overflow the nps[] buffer...
Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
{
"affected": [],
"aliases": [
"CVE-2022-48672"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-03T15:15:07Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nof: fdt: fix off-by-one error in unflatten_dt_nodes()\n\nCommit 78c44d910d3e (\"drivers/of: Fix depth when unflattening devicetree\")\nforgot to fix up the depth check in the loop body in unflatten_dt_nodes()\nwhich makes it possible to overflow the nps[] buffer...\n\nFound by Linux Verification Center (linuxtesting.org) with the SVACE static\nanalysis tool.",
"id": "GHSA-294m-6544-vprq",
"modified": "2024-06-03T18:53:45Z",
"published": "2024-05-03T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48672"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2133f451311671c7c42b5640d2b999326b39aa0e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2566706ac6393386a4e7c4ce23fe17f4c98d9aa0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f945a792f67815abca26fa8a5e863ccf3fa1181"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ba6b9f7cc1108bad6e2c53b1d6e0156379188db7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cbdda20ce363356698835185801a58a28f644853"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e0e88c25f88b9805572263c9ed20f1d88742feaf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ee4369260e77821602102dcc7d792de39a56365c"
}
],
"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-2CJ9-WJMR-5W57
Vulnerability from github – Published: 2024-03-11 15:31 – Updated: 2025-04-12 00:30An off-by-one error flaw was found in the udevListInterfacesByStatus() function in libvirt when the number of interfaces exceeds the size of the names array. This issue can be reproduced by sending specially crafted data to the libvirt daemon, allowing an unprivileged client to perform a denial of service attack by causing the libvirt daemon to crash.
{
"affected": [],
"aliases": [
"CVE-2024-1441"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-11T14:15:06Z",
"severity": "MODERATE"
},
"details": "An off-by-one error flaw was found in the udevListInterfacesByStatus() function in libvirt when the number of interfaces exceeds the size of the `names` array. This issue can be reproduced by sending specially crafted data to the libvirt daemon, allowing an unprivileged client to perform a denial of service attack by causing the libvirt daemon to crash.",
"id": "GHSA-2cj9-wjmr-5w57",
"modified": "2025-04-12T00:30:26Z",
"published": "2024-03-11T15:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1441"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:2560"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-1441"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2263841"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00000.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/45FFKU3LODT345LAB5T4XZA5WKYMXJYU"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/E6MVZO5GXDB7RHY6MS3ZXES3HPK34P3A"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250411-0003"
}
],
"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-2H29-RJH5-XXCH
Vulnerability from github – Published: 2022-05-13 01:13 – Updated: 2022-05-13 01:13QEMU (aka Quick Emulator) built with the Rocker switch emulation support is vulnerable to an off-by-one error. It happens while processing transmit (tx) descriptors in 'tx_consume' routine, if a descriptor was to have more than allowed (ROCKER_TX_FRAGS_MAX=16) fragments. A privileged user inside guest could use this flaw to cause memory leakage on the host or crash the QEMU process instance resulting in DoS issue.
{
"affected": [],
"aliases": [
"CVE-2015-8701"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-12-29T22:59:00Z",
"severity": "MODERATE"
},
"details": "QEMU (aka Quick Emulator) built with the Rocker switch emulation support is vulnerable to an off-by-one error. It happens while processing transmit (tx) descriptors in \u0027tx_consume\u0027 routine, if a descriptor was to have more than allowed (ROCKER_TX_FRAGS_MAX=16) fragments. A privileged user inside guest could use this flaw to cause memory leakage on the host or crash the QEMU process instance resulting in DoS issue.",
"id": "GHSA-2h29-rjh5-xxch",
"modified": "2022-05-13T01:13:40Z",
"published": "2022-05-13T01:13:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-8701"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1286971"
},
{
"type": "WEB",
"url": "https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg04629.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201602-01"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2015/12/28/6"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2015/12/29/1"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/79706"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2HFR-22WV-H4VJ
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-24 18:32In the Linux kernel, the following vulnerability has been resolved:
ceph: fix num_ops off-by-one when crypto allocation fails
move_dirty_folio_in_page_array() may fail if the file is encrypted, the dirty folio is not the first in the batch, and it fails to allocate a bounce buffer to hold the ciphertext. When that happens, ceph_process_folio_batch() simply redirties the folio and flushes the current batch -- it can retry that folio in a future batch.
However, if this failed folio is not contiguous with the last folio that
did make it into the batch, then ceph_process_folio_batch() has already
incremented ceph_wbc->num_ops; because it doesn't follow through and
add the discontiguous folio to the array, ceph_submit_write() -- which
expects that ceph_wbc->num_ops accurately reflects the number of
contiguous ranges (and therefore the required number of "write extent"
ops) in the writeback -- will panic the kernel:
BUG_ON(ceph_wbc->op_idx + 1 != req->r_num_ops);
This issue can be reproduced on affected kernels by writing to fscrypt-enabled CephFS file(s) with a 4KiB-written/4KiB-skipped/repeat pattern (total filesize should not matter) and gradually increasing the system's memory pressure until a bounce buffer allocation fails.
Fix this crash by decrementing ceph_wbc->num_ops back to the correct
value when move_dirty_folio_in_page_array() fails, but the folio already
started counting a new (i.e. still-empty) extent.
The defect corrected by this patch has existed since 2022 (see first
Fixes:), but another bug blocked multi-folio encrypted writeback until
recently (see second Fixes:). The second commit made it into 6.18.16,
6.19.6, and 7.0-rc1, unmasking the panic in those versions. This patch
therefore fixes a regression (panic) introduced by cac190c7674f.
{
"affected": [],
"aliases": [
"CVE-2026-46066"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix num_ops off-by-one when crypto allocation fails\n\nmove_dirty_folio_in_page_array() may fail if the file is encrypted, the\ndirty folio is not the first in the batch, and it fails to allocate a\nbounce buffer to hold the ciphertext. When that happens,\nceph_process_folio_batch() simply redirties the folio and flushes the\ncurrent batch -- it can retry that folio in a future batch.\n\nHowever, if this failed folio is not contiguous with the last folio that\ndid make it into the batch, then ceph_process_folio_batch() has already\nincremented `ceph_wbc-\u003enum_ops`; because it doesn\u0027t follow through and\nadd the discontiguous folio to the array, ceph_submit_write() -- which\nexpects that `ceph_wbc-\u003enum_ops` accurately reflects the number of\ncontiguous ranges (and therefore the required number of \"write extent\"\nops) in the writeback -- will panic the kernel:\n\n BUG_ON(ceph_wbc-\u003eop_idx + 1 != req-\u003er_num_ops);\n\nThis issue can be reproduced on affected kernels by writing to\nfscrypt-enabled CephFS file(s) with a 4KiB-written/4KiB-skipped/repeat\npattern (total filesize should not matter) and gradually increasing the\nsystem\u0027s memory pressure until a bounce buffer allocation fails.\n\nFix this crash by decrementing `ceph_wbc-\u003enum_ops` back to the correct\nvalue when move_dirty_folio_in_page_array() fails, but the folio already\nstarted counting a new (i.e. still-empty) extent.\n\nThe defect corrected by this patch has existed since 2022 (see first\n`Fixes:`), but another bug blocked multi-folio encrypted writeback until\nrecently (see second `Fixes:`). The second commit made it into 6.18.16,\n6.19.6, and 7.0-rc1, unmasking the panic in those versions. This patch\ntherefore fixes a regression (panic) introduced by cac190c7674f.",
"id": "GHSA-2hfr-22wv-h4vj",
"modified": "2026-06-24T18:32:29Z",
"published": "2026-05-27T15:33:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46066"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6200f41d6fcf2ac7e24866431e381cbc914560e4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a0d9555bf9eaeba34fe6b6bb86f442fe08ba3842"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ba12c1e578890f6337a415b7dedf476c6d455105"
}
],
"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-2V9G-P8FQ-VVH2
Vulnerability from github – Published: 2022-02-19 00:01 – Updated: 2022-03-17 00:05An off-by-one error was found in the SCSI device emulation in QEMU. It could occur while processing MODE SELECT commands in mode_sense_page() if the 'page' argument was set to MODE_PAGE_ALLS (0x3f). A malicious guest could use this flaw to potentially crash QEMU, resulting in a denial of service condition.
{
"affected": [],
"aliases": [
"CVE-2021-3930"
],
"database_specific": {
"cwe_ids": [
"CWE-193"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-18T18:15:00Z",
"severity": "MODERATE"
},
"details": "An off-by-one error was found in the SCSI device emulation in QEMU. It could occur while processing MODE SELECT commands in mode_sense_page() if the \u0027page\u0027 argument was set to MODE_PAGE_ALLS (0x3f). A malicious guest could use this flaw to potentially crash QEMU, resulting in a denial of service condition.",
"id": "GHSA-2v9g-p8fq-vvh2",
"modified": "2022-03-17T00:05:29Z",
"published": "2022-02-19T00:01:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3930"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2020588"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/04/msg00002.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/09/msg00008.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202208-27"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220225-0007"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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: 2022-05-24 17:17An 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": "2022-05-24T17:17:57Z",
"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;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": []
}
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"
}
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.