Common Weakness Enumeration

CWE-193

Allowed

Off-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:31
VLAI
Details

In 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.

Show details on source website

{
  "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:31
VLAI
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.

Show details on source website

{
  "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:31
VLAI
Details

In 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.

Show details on source website

{
  "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:16
VLAI
Summary
nimiq-blockchain: Validity store off by one error
Details

Impact

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

Show details on source website

{
  "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:31
VLAI
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.

Show details on source website

{
  "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:31
VLAI
Details

Windows Kernel Denial of Service Vulnerability.

Show details on source website

{
  "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:34
VLAI
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.

Show details on source website

{
  "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:53
VLAI
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.

Show details on source website

{
  "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:30
VLAI
Details

arduino-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.

Show details on source website

{
  "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:30
VLAI
Details

In 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.

Show details on source website

{
  "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
Implementation

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.