Common Weakness Enumeration

CWE-190

Allowed

Integer Overflow or Wraparound

Abstraction: Base · Status: Stable

The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number.

3867 vulnerabilities reference this CWE, most recent first.

GHSA-96HC-CM5R-3PR6

Vulnerability from github – Published: 2024-08-14 15:31 – Updated: 2025-11-04 00:31
VLAI
Details

Integer overflow in firmware for some Intel(R) CSME may allow an unauthenticated user to potentially enable denial of service via adjacent access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-21844"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-14T14:15:17Z",
    "severity": "MODERATE"
  },
  "details": "Integer overflow in firmware for some Intel(R) CSME may allow an unauthenticated user to potentially enable denial of service via adjacent access.",
  "id": "GHSA-96hc-cm5r-3pr6",
  "modified": "2025-11-04T00:31:11Z",
  "published": "2024-08-14T15:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21844"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20241108-0003"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00999.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/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-96JV-R488-C2RJ

Vulnerability from github – Published: 2023-01-10 03:30 – Updated: 2023-01-13 17:18
VLAI
Summary
bzip2 allows attackers to cause a denial of service via a large file that triggers an integer overflow
Details

The bzip2 crate before 0.4.4 for Rust allow attackers to cause a denial of service via a large file that triggers an integer overflow in mem.rs. NOTE: this is unrelated to the https://crates.io/crates/bzip2-rs product.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "bzip2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-22895"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-10T22:10:17Z",
    "nvd_published_at": "2023-01-10T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "The bzip2 crate before 0.4.4 for Rust allow attackers to cause a denial of service via a large file that triggers an integer overflow in `mem.rs`. NOTE: this is unrelated to the https://crates.io/crates/bzip2-rs product.",
  "id": "GHSA-96jv-r488-c2rj",
  "modified": "2023-01-13T17:18:40Z",
  "published": "2023-01-10T03:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22895"
    },
    {
      "type": "WEB",
      "url": "https://github.com/alexcrichton/bzip2-rs/pull/86"
    },
    {
      "type": "WEB",
      "url": "https://github.com/alexcrichton/bzip2-rs/commit/90c9c182cd5a5ebc75810aebd89b347a7bdf590b"
    },
    {
      "type": "WEB",
      "url": "https://crates.io/crates/bzip2/versions"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/alexcrichton/bzip2-rs"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MI5SVRSGKBWB2JGDLDVIFY5ZQVDZP6I7"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SQK57GGXJX3AH7KF6S7S3N7JC5QOYUQ7"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UUK2JO25PPA6XBREKJRBLRCD22LKIOLO"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2023-0004.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "bzip2 allows attackers to cause a denial of service via a large file that triggers an integer overflow"
}

GHSA-96MQ-P6QX-9H4C

Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-05-13 01:01
VLAI
Details

An exploitable integer overflow exists in the TIFF loading functionality of the Blender open-source 3d creation suite version 2.78c. A specially crafted '.tif' file can cause an integer overflow resulting in a buffer overflow which can allow for code execution under the context of the application. An attacker can convince a user to use the file as an asset via the sequencer in order to trigger this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-2899"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-04-24T19:29:00Z",
    "severity": "HIGH"
  },
  "details": "An exploitable integer overflow exists in the TIFF loading functionality of the Blender open-source 3d creation suite version 2.78c. A specially crafted \u0027.tif\u0027 file can cause an integer overflow resulting in a buffer overflow which can allow for code execution under the context of the application. An attacker can convince a user to use the file as an asset via the sequencer in order to trigger this vulnerability.",
  "id": "GHSA-96mq-p6qx-9h4c",
  "modified": "2022-05-13T01:01:15Z",
  "published": "2022-05-13T01:01:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2899"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/08/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2018/dsa-4248"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0406"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-96WX-HQJC-PV4Q

Vulnerability from github – Published: 2025-09-23 21:30 – Updated: 2025-09-23 21:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix qgroup reserve overflow the qgroup limit

We use extent_changeset->bytes_changed in qgroup_reserve_data() to record how many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the bytes_changed is set as "unsigned int", and it will overflow if we try to fallocate a range larger than 4GiB. The result is we reserve less bytes and eventually break the qgroup limit.

Unlike regular buffered/direct write, which we use one changeset for each ordered extent, which can never be larger than 256M. For fallocate, we use one changeset for the whole range, thus it no longer respects the 256M per extent limit, and caused the problem.

The following example test script reproduces the problem:

$ cat qgroup-overflow.sh #!/bin/bash

DEV=/dev/sdj MNT=/mnt/sdj

mkfs.btrfs -f $DEV mount $DEV $MNT

# Set qgroup limit to 2GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT

# Try to fallocate a 3GiB file. This should fail. echo echo "Try to fallocate a 3GiB file..." fallocate -l 3G $MNT/3G.file

# Try to fallocate a 5GiB file. echo echo "Try to fallocate a 5GiB file..." fallocate -l 5G $MNT/5G.file

# See we break the qgroup limit. echo sync btrfs qgroup show -r $MNT

umount $MNT

When running the test:

$ ./qgroup-overflow.sh (...)

Try to fallocate a 3GiB file... fallocate: fallocate failed: Disk quota exceeded

Try to fallocate a 5GiB file...

qgroupid         rfer         excl     max_rfer --------         ----         ----     -------- 0/5           5.00GiB      5.00GiB      2.00GiB

Since we have no control of how bytes_changed is used, it's better to set it to u64.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49075"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:00:44Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix qgroup reserve overflow the qgroup limit\n\nWe use extent_changeset-\u003ebytes_changed in qgroup_reserve_data() to record\nhow many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the\nbytes_changed is set as \"unsigned int\", and it will overflow if we try to\nfallocate a range larger than 4GiB. The result is we reserve less bytes\nand eventually break the qgroup limit.\n\nUnlike regular buffered/direct write, which we use one changeset for\neach ordered extent, which can never be larger than 256M.  For\nfallocate, we use one changeset for the whole range, thus it no longer\nrespects the 256M per extent limit, and caused the problem.\n\nThe following example test script reproduces the problem:\n\n  $ cat qgroup-overflow.sh\n  #!/bin/bash\n\n  DEV=/dev/sdj\n  MNT=/mnt/sdj\n\n  mkfs.btrfs -f $DEV\n  mount $DEV $MNT\n\n  # Set qgroup limit to 2GiB.\n  btrfs quota enable $MNT\n  btrfs qgroup limit 2G $MNT\n\n  # Try to fallocate a 3GiB file. This should fail.\n  echo\n  echo \"Try to fallocate a 3GiB file...\"\n  fallocate -l 3G $MNT/3G.file\n\n  # Try to fallocate a 5GiB file.\n  echo\n  echo \"Try to fallocate a 5GiB file...\"\n  fallocate -l 5G $MNT/5G.file\n\n  # See we break the qgroup limit.\n  echo\n  sync\n  btrfs qgroup show -r $MNT\n\n  umount $MNT\n\nWhen running the test:\n\n  $ ./qgroup-overflow.sh\n  (...)\n\n  Try to fallocate a 3GiB file...\n  fallocate: fallocate failed: Disk quota exceeded\n\n  Try to fallocate a 5GiB file...\n\n  qgroupid\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 rfer\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 excl\u00a0\u00a0\u00a0\u00a0 max_rfer\n  --------\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ----\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ----\u00a0\u00a0\u00a0\u00a0 --------\n  0/5\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 5.00GiB\u00a0\u00a0\u00a0\u00a0\u00a0 5.00GiB\u00a0\u00a0\u00a0\u00a0\u00a0 2.00GiB\n\nSince we have no control of how bytes_changed is used, it\u0027s better to\nset it to u64.",
  "id": "GHSA-96wx-hqjc-pv4q",
  "modified": "2025-09-23T21:30:54Z",
  "published": "2025-09-23T21:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49075"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0355387ea5b02d353c9415613fab908fac5c52a6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/44277c50fdba5019ca25bfad1b71e2561b0de11b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4b98799e181b4326a613108cf37acc1f55d21b45"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6bfff81286d4491f02dad7814bae5c77c9ad2320"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7941b74ed49b6db25efbef2256ebef843c11a010"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/82ae73ac963cee877ce34f7c31b2b456b516e96c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b642b52d0b50f4d398cb4293f64992d0eed2e2ce"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f3d97b22a708bf9e3f3ac2ba232bcefd0b0c136b"
    }
  ],
  "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-96XM-FV9W-PF3F

Vulnerability from github – Published: 2026-01-28 22:20 – Updated: 2026-01-29 03:56
VLAI
Summary
soroban-sdk has overflow in Bytes::slice, Vec::slice, GenRange::gen_range for u64
Details

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice: - Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range. - Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice: - Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty. - Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range: - Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range. - Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs: - Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0). - Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

  • Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
  • Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

  • https://github.com/stellar/rs-soroban-sdk/pull/1703
  • https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
  • https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
  • https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "soroban-sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "25.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "soroban-sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "23.0.0"
            },
            {
              "fixed": "23.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "soroban-sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "22.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24889"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-28T22:20:35Z",
    "nvd_published_at": "2026-01-28T22:15:56Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nArithmetic overflow can be triggered in the `Bytes::slice`, `Vec::slice`, and `Prng::gen_range` (for `u64`) methods in the `soroban-sdk` in versions prior to and including `25.0.1`.\n\nContracts that pass user-controlled or computed range bounds to `Bytes::slice`, `Vec::slice`, or `Prng::gen_range` may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.\n\nNote that the best practice when using the `soroban-sdk` and building Soroban contracts is to always enable `overflow-checks = true`. The `stellar contract init` tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring `overflow-checks = true` on `release` profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use `overflow-checks = false` either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable `overflow-checks`.\n\n### Detail\n\nWhen compiled with `overflow-checks = false` (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like `u32::MAX` or `u64::MAX`. This causes the range passed to the host to differ from the caller\u0027s intent:\n\n`Bytes::slice`:\n- `Bytes::slice(0..=u32::MAX)` \u2014 end `u32::MAX + 1` wraps to `0`, producing `slice(0..0)` returning empty instead of the full range.\n- `Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded))` \u2014 start `u32::MAX + 1` wraps to `0`, producing `slice(0..)` instead of an empty/invalid range.\n\n`Vec::slice`:\n- `Vec::slice(0..=u32::MAX)` \u2014 same as `Bytes`, end wraps to `0`, returning empty.\n- `Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded))` \u2014 same as `Bytes`, start wraps to `0`.\n\n`Prng::gen_range`:\n- `Prng::gen_range((Bound::Unbounded, Bound::Excluded(0)))` \u2014 end `0 - 1` wraps to `u64::MAX`, producing range `0..=u64::MAX` instead of an empty/invalid range.\n- `Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded))` \u2014 start `u64::MAX + 1` wraps to `0`, producing range `0..=u64::MAX` instead of an empty/invalid range.\n\nNote that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error `HostError: Error(Object, IndexBounds)` `object index out of bounds`, because the wrapped values create invalid inputs:\n- `Bytes::slice(u32::MAX..=u32::MAX)` \u2014 both start `u32::MAX + 1` and end `u32::MAX + 1` wrap to `0`, producing `slice(0..0)`.\n- `Vec::slice(u32::MAX..=u32::MAX)` \u2014 same as `Bytes`, both wrap to `0`.\n\n\n### Patches\n\nThe fix replaces bare arithmetic with `checked_add` / `checked_sub`, ensuring overflow traps regardless of the `overflow-checks` profile setting.\n\n### Workarounds\n\nContract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using `stellar contract init`:\n\n```toml\n[profile.release]\noverflow-checks = true\n```\n\nAlternatively, contracts can validate range bounds before passing them to `slice` or `gen_range` to ensure the conversions cannot overflow:\n\n- Do not pass `Bound::Excluded(u32::MAX)` or `Bound::Included(u32::MAX)` to `Bytes::slice` or `Vec::slice`.\n- Do not pass `Bound::Excluded(u64::MAX)` as a start bound or `Bound::Excluded(0)` as an end bound to `Prng::gen_range::\u003cu64\u003e`.\n\n### References\n\n- https://github.com/stellar/rs-soroban-sdk/pull/1703\n- https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2\n- https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1\n- https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9",
  "id": "GHSA-96xm-fv9w-pf3f",
  "modified": "2026-01-29T03:56:38Z",
  "published": "2026-01-28T22:20:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-sdk/security/advisories/GHSA-96xm-fv9w-pf3f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24889"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-sdk/pull/1703"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-sdk/commit/3890521426d71bb4d892b21f5a283a1e836cfa38"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-sdk/commit/59fcef437260ed4da42d1efb357137a5c166c02e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-sdk/commit/c2757c6d774dbb28b34a0b77ffe282e59f0f8462"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/stellar/rs-soroban-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "soroban-sdk has overflow in Bytes::slice, Vec::slice, GenRange::gen_range for u64"
}

GHSA-978F-5QGH-63FX

Vulnerability from github – Published: 2022-05-13 01:28 – Updated: 2022-05-13 01:28
VLAI
Details

Integer overflow in the queue_init function in unsquashfs.c in unsquashfs in Squashfs 4.2 and earlier allows remote attackers to execute arbitrary code via a crafted block_log field in the superblock of a .sqsh file, leading to a heap-based buffer overflow.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2012-4025"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-07-19T19:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Integer overflow in the queue_init function in unsquashfs.c in unsquashfs in Squashfs 4.2 and earlier allows remote attackers to execute arbitrary code via a crafted block_log field in the superblock of a .sqsh file, leading to a heap-based buffer overflow.",
  "id": "GHSA-978f-5qgh-63fx",
  "modified": "2022-05-13T01:28:57Z",
  "published": "2022-05-13T01:28:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-4025"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201612-40"
    },
    {
      "type": "WEB",
      "url": "https://wiki.mageia.org/en/Support/Advisories/MGASA-2013-0001"
    },
    {
      "type": "WEB",
      "url": "http://sourceforge.net/mailarchive/forum.php?thread_name=CAAoG81HL9oP8roPLLhftTSXTzSD%2BZcR66PRkVU%3Df76W3Mjde_w%40mail.gmail.com\u0026forum_name=squashfs-devel"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2013:128"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2012/07/19/6"
    },
    {
      "type": "WEB",
      "url": "http://www.osvdb.org/83899"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/54610"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-979V-WQ6C-52Q5

Vulnerability from github – Published: 2022-05-14 03:12 – Updated: 2022-05-14 03:12
VLAI
Details

The mintToken function of a smart contract implementation for BTPCoin, an Ethereum token, has an integer overflow that allows the owner of the contract to set the balance of an arbitrary user to any value.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-13668"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-07-09T06:29:00Z",
    "severity": "HIGH"
  },
  "details": "The mintToken function of a smart contract implementation for BTPCoin, an Ethereum token, has an integer overflow that allows the owner of the contract to set the balance of an arbitrary user to any value.",
  "id": "GHSA-979v-wq6c-52q5",
  "modified": "2022-05-14T03:12:36Z",
  "published": "2022-05-14T03:12:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-13668"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BlockChainsSecurity/EtherTokens/blob/master/GEMCHAIN/mint%20integer%20overflow.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BlockChainsSecurity/EtherTokens/tree/master/BTPCoin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-97F8-83VC-C97Q

Vulnerability from github – Published: 2022-02-10 00:01 – Updated: 2022-06-15 00:00
VLAI
Details

storeAtts in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-22827"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-10T14:12:00Z",
    "severity": "HIGH"
  },
  "details": "storeAtts in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow.",
  "id": "GHSA-97f8-83vc-c97q",
  "modified": "2022-06-15T00:00:29Z",
  "published": "2022-02-10T00:01:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22827"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libexpat/libexpat/pull/539"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-484086.pdf"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202209-24"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2022/dsa-5073"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/tns-2022-05"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/01/17/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-97WC-2HQC-CJGR

Vulnerability from github – Published: 2026-05-09 00:02 – Updated: 2026-06-08 23:35
VLAI
Summary
smallbitvec: Integer overflow in safe API leads to heap buffer overflow
Details

Summary

An integer overflow in the internal capacity calculation of smallbitvec can lead to an undersized heap allocation, resulting in a heap buffer overflow through safe APIs only. This allows memory corruption without requiring unsafe code from the caller.

Details

The issue originates from unchecked arithmetic in the internal helper function responsible for computing the required buffer size:

(cap + bits_per_storage() - 1) / bits_per_storage()

When cap is close to usize::MAX, the addition:

cap + bits_per_storage() - 1

can overflow in release builds and wrap around due to Rust’s default wrapping semantics for integer overflow in optimized builds.

As a result: - buffer_len(cap) may return a value significantly smaller than required. - The backing storage is allocated with insufficient size. - Internal metadata (logical length/capacity) reflects a much larger size than the actual allocation.

Subsequent safe API calls (e.g., set, push, reserve) rely on this corrupted metadata and perform index computations that assume sufficient backing storage. These operations eventually reach unsafe internal code paths (e.g., pointer arithmetic and unchecked indexing), leading to out-of-bounds memory access.

Summary of the issue: integer overflow → undersized allocation → inconsistent metadata (len/cap vs actual buffer) → unsafe internal access using corrupted metadata → heap buffer overflow (UB)

PoC

PoC 1: Out-of-bounds write via from_elem

#![forbid(unsafe_code)]

use smallbitvec::SmallBitVec;

fn main() {
    // Triggers overflow in buffer_len(cap)
    let mut v = SmallBitVec::from_elem(usize::MAX, false);

    // Logical length is large, but backing storage is undersized
    // This leads to out-of-bounds write in unsafe internals
    v.set(0, true);
}

PoC 2: Overflow via reserve

#![forbid(unsafe_code)]

use smallbitvec::SmallBitVec;

fn main() {
    let mut v = SmallBitVec::new();
    v.push(true);

    // Triggers overflow in capacity computation
    v.reserve(usize::MAX - 10);
}

Impact

  • Heap buffer overflow via safe API only
  • ASAN-observable heap-buffer-overflow
  • Undefined Behavior detectable with Miri (e.g., out-of-bounds indexing due to corrupted metadata)

Tested on

  • rustc 1.96.0-nightly (9602bda1d 2026-04-05)
  • Target: x86_64-unknown-linux-gnu
  • Build: release
  • ASAN: RUSTFLAGS="-Z sanitizer=address" cargo +nightly run --release
  • Miri: cargo +nightly miri run --release
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "smallbitvec"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.1"
            },
            {
              "last_affected": "2.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44983"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-122",
      "CWE-190"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-09T00:02:47Z",
    "nvd_published_at": "2026-05-26T22:16:43Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nAn integer overflow in the internal capacity calculation of `smallbitvec` can lead to an undersized heap allocation, resulting in a heap buffer overflow through safe APIs only. This allows memory corruption without requiring `unsafe` code from the caller.\n\n### Details\nThe issue originates from unchecked arithmetic in the internal helper function responsible for computing the required buffer size:\n\n```\n(cap + bits_per_storage() - 1) / bits_per_storage()\n```\n\nWhen `cap` is close to `usize::MAX`, the addition:\n\n```\ncap + bits_per_storage() - 1\n```\n\ncan overflow in release builds and wrap around due to Rust\u2019s default wrapping semantics for integer overflow in optimized builds.\n\nAs a result:\n- `buffer_len(cap)` may return a value significantly smaller than required.\n- The backing storage is allocated with insufficient size.\n- Internal metadata (logical length/capacity) reflects a much larger size than the actual allocation.\n\nSubsequent safe API calls (e.g., `set`, `push`, `reserve`) rely on this corrupted metadata and perform index computations that assume sufficient backing storage. These operations eventually reach unsafe internal code paths (e.g., pointer arithmetic and unchecked indexing), leading to out-of-bounds memory access.\n\nSummary of the issue:\ninteger overflow\n\u2192 undersized allocation\n\u2192 inconsistent metadata (len/cap vs actual buffer)\n\u2192 unsafe internal access using corrupted metadata\n\u2192 heap buffer overflow (UB)\n### PoC\n#### PoC 1: Out-of-bounds write via `from_elem`\n```rust\n#![forbid(unsafe_code)]\n\nuse smallbitvec::SmallBitVec;\n\nfn main() {\n    // Triggers overflow in buffer_len(cap)\n    let mut v = SmallBitVec::from_elem(usize::MAX, false);\n\n    // Logical length is large, but backing storage is undersized\n    // This leads to out-of-bounds write in unsafe internals\n    v.set(0, true);\n}\n```\n#### PoC 2: Overflow via `reserve`\n```rust\n#![forbid(unsafe_code)]\n\nuse smallbitvec::SmallBitVec;\n\nfn main() {\n    let mut v = SmallBitVec::new();\n    v.push(true);\n\n    // Triggers overflow in capacity computation\n    v.reserve(usize::MAX - 10);\n}\n```\n\n### Impact\n- Heap buffer overflow via safe API only\n- ASAN-observable heap-buffer-overflow\n- Undefined Behavior detectable with Miri (e.g., out-of-bounds indexing due to corrupted metadata)\n\n### Tested on\n- rustc 1.96.0-nightly (9602bda1d 2026-04-05)\n- Target: x86_64-unknown-linux-gnu\n- Build: release\n- ASAN: `RUSTFLAGS=\"-Z sanitizer=address\" cargo +nightly run --release`\n- Miri: `cargo +nightly miri run --release`",
  "id": "GHSA-97wc-2hqc-cjgr",
  "modified": "2026-06-08T23:35:08Z",
  "published": "2026-05-09T00:02:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/servo/smallbitvec/security/advisories/GHSA-97wc-2hqc-cjgr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44983"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/servo/smallbitvec"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "smallbitvec: Integer overflow in safe API leads to heap buffer overflow"
}

GHSA-97XH-JVGW-7W42

Vulnerability from github – Published: 2024-01-08 15:30 – Updated: 2024-04-09 21:31
VLAI
Details

Multiple integer overflow vulnerabilities exist in the LXT2 facgeometry parsing functionality of GTKWave 3.3.115. A specially crafted .lxt2 file can lead to arbitrary code execution. A victim would need to open a malicious file to trigger these vulnerabilities.This vulnerability concerns the integer overflow when allocating the flags array.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-39273"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-08T15:15:23Z",
    "severity": "HIGH"
  },
  "details": "Multiple integer overflow vulnerabilities exist in the LXT2 facgeometry parsing functionality of GTKWave 3.3.115. A specially crafted .lxt2 file can lead to arbitrary code execution. A victim would need to open a malicious file to trigger these vulnerabilities.This vulnerability concerns the integer overflow when allocating the `flags` array.",
  "id": "GHSA-97xh-jvgw-7w42",
  "modified": "2024-04-09T21:31:55Z",
  "published": "2024-01-08T15:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39273"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2023-1818"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2023-1818"
    }
  ],
  "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"
    }
  ]
}

Mitigation
Requirements

Ensure that all protocols are strictly defined, such that all out-of-bounds behavior can be identified simply, and require strict conformance to the protocol.

Mitigation MIT-3
Requirements

Strategy: Language Selection

  • Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • If possible, choose a language or compiler that performs automatic bounds checking.
Mitigation MIT-4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
  • Use libraries or frameworks that make it easier to handle numbers without unexpected consequences.
  • Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]
Mitigation MIT-8
Implementation

Strategy: Input Validation

  • Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.
  • Use unsigned integers where possible. This makes it easier to perform validation for integer overflows. When signed integers are required, ensure that the range check includes minimum values as well as maximum values.
Mitigation MIT-36
Implementation
  • Understand the programming language's underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7]
  • Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.
Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation MIT-26
Implementation

Strategy: Compilation or Build Hardening

Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.

CAPEC-92: Forced Integer Overflow

This attack forces an integer variable to go out of range. The integer variable is often used as an offset such as size of memory allocation or similarly. The attacker would typically control the value of such variable and try to get it out of range. For instance the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing a very incorrect value which can lead to unexpected behavior. At worst the attacker can execute arbitrary code.