{"id":"CVE-2024-4435","aliases":["EUVD-2024-1394","GHSA-3rcq-39xp-7xjp","RUSTSEC-2024-0406"],"status":"published","title":"BTreeMap memory leak when deallocating nodes with overflows","description":"When storing unbounded types in a BTreeMap, a node is represented as a linked list of \"memory chunks\". It was discovered recently that when we deallocate a node, in some cases only the first memory chunk is deallocated, and the rest of the memory chunks remain (incorrectly) allocated, causing a memory leak. In the worst case, depending on how a canister uses the BTreeMap, an adversary could interact with the canister through its API and trigger interactions with the map that keep consuming memory due to the memory leak. This could potentially lead to using an excessive amount of memory, or even running out of memory.\n\nThis issue has been fixed in  #212 https://github.com/dfinity/stable-structures/pull/212  by changing the logic for deallocating nodes to ensure that all of a node's memory chunks are deallocated and users are asked to upgrade to version 0.6.4.. Tests have been added to prevent regressions of this nature moving forward. Note: Users of stable-structure \u003c 0.6.0 are not affected.\n\nUsers who are not storing unbounded types in BTreeMap are not affected and do not need to upgrade. Otherwise, an upgrade to version 0.6.4 is necessary.","severity":{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00515,"percentile":0.44227,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-401"],"published":"2024-05-17T12:00:00Z","modified":"2026-10-28T02:30:32Z","fixes":[{"ecosystem":"crates.io","package":"ic-stable-structures","fixed_in":["0.6.4"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"crates.io","package":"ic-stable-structures","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.6.0"},{"fixed":"0.6.4"}]}]},{"source":"osv","ecosystem":"crates.io","package":"ic-stable-structures","ranges":[{"type":"SEMVER","events":[{"introduced":"0.6.0"},{"fixed":"0.6.4"}]}]},{"source":"osv","ecosystem":"crates.io","package":"ic-stable-structures","ranges":[{"type":"SEMVER","events":[{"introduced":"0.6.0"},{"fixed":"0.6.4"}]}]}],"products":[{"vendor":"dfinity","product":"stable_structures"},{"vendor":"internet computer","product":"ic-stable-structures"}],"references":[{"url":"https://github.com/dfinity/stable-structures/pull/212","tags":["x_transferred","Issue Tracking","Patch","fix","web"]},{"url":"https://docs.rs/ic-stable-structures/0.6.4/ic_stable_structures/","tags":["x_transferred","Product","web"]},{"url":"https://internetcomputer.org/docs/current/developer-docs/smart-contracts/maintain/storage#stable-memory","tags":["x_transferred","Product","web"]},{"url":"https://github.com/dfinity/stable-structures/security/advisories/GHSA-3rcq-39xp-7xjp","tags":["web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-4435","tags":["advisory"]},{"url":"https://github.com/dfinity/stable-structures/commit/4f6b8ae521884833498bae26369c353c10f28ea7","tags":["web"]},{"url":"https://docs.rs/ic-stable-structures/0.6.4/ic_stable_structures","tags":["web"]},{"url":"https://rustsec.org/advisories/RUSTSEC-2024-0406.html","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-3rcq-39xp-7xjp"},{"url":"https://crates.io/crates/ic-stable-structures","tags":["web","package"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/4xxx/CVE-2024-4435.json","tags":["advisory"]},{"url":"https://github.com/dfinity/stable-structures","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2024-4435","title":"BTreeMap memory leak when deallocating nodes with overflows","description":"When storing unbounded types in a BTreeMap, a node is represented as a linked list of \"memory chunks\". It was discovered recently that when we deallocate a node, in some cases only the first memory chunk is deallocated, and the rest of the memory chunks remain (incorrectly) allocated, causing a memory leak. In the worst case, depending on how a canister uses the BTreeMap, an adversary could interact with the canister through its API and trigger interactions with the map that keep consuming memory due to the memory leak. This could potentially lead to using an excessive amount of memory, or even running out of memory.\n\nThis issue has been fixed in  #212 https://github.com/dfinity/stable-structures/pull/212  by changing the logic for deallocating nodes to ensure that all of a node's memory chunks are deallocated and users are asked to upgrade to version 0.6.4.. Tests have been added to prevent regressions of this nature moving forward. Note: Users of stable-structure \u003c 0.6.0 are not affected.\n\nUsers who are not storing unbounded types in BTreeMap are not affected and do not need to upgrade. Otherwise, an upgrade to version 0.6.4 is necessary.","status":"published","published":"2024-05-21T09:41:35.242Z","modified":"2024-08-01T20:40:47.18Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"cna"}],"cwes":["CWE-401"],"updated_at":"2026-11-02T14:34:16.78507Z"}],"euvd":[{"id":"EUVD-2024-1394","description":"When storing unbounded types in a BTreeMap, a node is represented as a linked list of \"memory chunks\". It was discovered recently that when we deallocate a node, in some cases only the first memory chunk is deallocated, and the rest of the memory chunks remain (incorrectly) allocated, causing a memory leak. In the worst case, depending on how a canister uses the BTreeMap, an adversary could interact with the canister through its API and trigger interactions with the map that keep consuming memory due to the memory leak. This could potentially lead to using an excessive amount of memory, or even running out of memory.\n\nThis issue has been fixed in  #212 https://github.com/dfinity/stable-structures/pull/212  by changing the logic for deallocating nodes to ensure that all of a node's memory chunks are deallocated and users are asked to upgrade to version 0.6.4.. Tests have been added to prevent regressions of this nature moving forward. Note: Users of stable-structure \u003c 0.6.0 are not affected.\n\nUsers who are not storing unbounded types in BTreeMap are not affected and do not need to upgrade. Otherwise, an upgrade to version 0.6.4 is necessary.","status":"published","published":"2024-05-21T09:41:35Z","modified":"2024-08-01T20:40:47Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-03T03:50:36.775345Z"}],"ghsa":[{"id":"GHSA-3rcq-39xp-7xjp","title":"ic-stable-structures vulnerable to BTreeMap memory leak when deallocating nodes with overflows","description":"### Impact\nWhen storing unbounded types in a `BTreeMap`, a node is represented as a linked list of \"memory chunks\". It was discovered recently that when we deallocate a node, in some cases only the first memory chunk is deallocated, and the rest of the memory chunks remain (incorrectly) allocated, causing a memory leak.\n\nIn the worst case, depending on how a canister uses the `BTreeMap`, an adversary could interact with the canister through its API and trigger interactions with the map that keep consuming memory due to the memory leak. This could potentially lead to using an excessive amount of memory, or even running out of memory. \n\nThis issue has been fixed in #212 by changing the logic for deallocating nodes to ensure that all of a node's memory chunks are deallocated. Tests have been added to prevent regressions of this nature moving forward.\n\n**Note:** Users of stable-structure \u003c 0.6.0 are not affected.\n\n### Patches\nThe problem has been fixed in PR #212 and users are asked to upgrade to version `0.6.4`.\n\n### Workarounds\nUsers who are not storing unbounded types in `BTreeMap` are not affected and do not need to upgrade. Otherwise, an upgrade to version `0.6.4` is necessary.","status":"published","published":"2024-05-21T14:49:48Z","modified":"2025-12-10T18:45:25Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-401"],"updated_at":"2026-11-02T14:39:12.222121Z"}],"nvd":[{"id":"CVE-2024-4435","description":"When storing unbounded types in a BTreeMap, a node is represented as a linked list of \"memory chunks\". It was discovered recently that when we deallocate a node, in some cases only the first memory chunk is deallocated, and the rest of the memory chunks remain (incorrectly) allocated, causing a memory leak. In the worst case, depending on how a canister uses the BTreeMap, an adversary could interact with the canister through its API and trigger interactions with the map that keep consuming memory due to the memory leak. This could potentially lead to using an excessive amount of memory, or even running out of memory.\n\nThis issue has been fixed in  #212 https://github.com/dfinity/stable-structures/pull/212  by changing the logic for deallocating nodes to ensure that all of a node's memory chunks are deallocated and users are asked to upgrade to version 0.6.4.. Tests have been added to prevent regressions of this nature moving forward. Note: Users of stable-structure \u003c 0.6.0 are not affected.\n\nUsers who are not storing unbounded types in BTreeMap are not affected and do not need to upgrade. Otherwise, an upgrade to version 0.6.4 is necessary.","status":"published","published":"2024-05-21T10:15:10.393Z","modified":"2026-06-17T08:01:52.543Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"secondary"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"primary"}],"cwes":["CWE-401"],"updated_at":"2026-11-02T14:10:01.327642Z"}],"osv":[{"id":"CVE-2024-4435","title":"BTreeMap memory leak when deallocating nodes with overflows","description":"When storing unbounded types in a BTreeMap, a node is represented as a linked list of \"memory chunks\". It was discovered recently that when we deallocate a node, in some cases only the first memory chunk is deallocated, and the rest of the memory chunks remain (incorrectly) allocated, causing a memory leak. In the worst case, depending on how a canister uses the BTreeMap, an adversary could interact with the canister through its API and trigger interactions with the map that keep consuming memory due to the memory leak. This could potentially lead to using an excessive amount of memory, or even running out of memory.\n\nThis issue has been fixed in  #212 https://github.com/dfinity/stable-structures/pull/212  by changing the logic for deallocating nodes to ensure that all of a node's memory chunks are deallocated and users are asked to upgrade to version 0.6.4.. Tests have been added to prevent regressions of this nature moving forward. Note: Users of stable-structure \u003c 0.6.0 are not affected.\n\nUsers who are not storing unbounded types in BTreeMap are not affected and do not need to upgrade. Otherwise, an upgrade to version 0.6.4 is necessary.","status":"published","published":"2024-05-21T09:41:35.242Z","modified":"2026-10-28T02:30:32.779849988Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-401"],"updated_at":"2026-11-02T15:44:42.322107Z"},{"id":"GHSA-3rcq-39xp-7xjp","title":"ic-stable-structures vulnerable to BTreeMap memory leak when deallocating nodes with overflows","description":"### Impact\nWhen storing unbounded types in a `BTreeMap`, a node is represented as a linked list of \"memory chunks\". It was discovered recently that when we deallocate a node, in some cases only the first memory chunk is deallocated, and the rest of the memory chunks remain (incorrectly) allocated, causing a memory leak.\n\nIn the worst case, depending on how a canister uses the `BTreeMap`, an adversary could interact with the canister through its API and trigger interactions with the map that keep consuming memory due to the memory leak. This could potentially lead to using an excessive amount of memory, or even running out of memory. \n\nThis issue has been fixed in #212 by changing the logic for deallocating nodes to ensure that all of a node's memory chunks are deallocated. Tests have been added to prevent regressions of this nature moving forward.\n\n**Note:** Users of stable-structure \u003c 0.6.0 are not affected.\n\n### Patches\nThe problem has been fixed in PR #212 and users are asked to upgrade to version `0.6.4`.\n\n### Workarounds\nUsers who are not storing unbounded types in `BTreeMap` are not affected and do not need to upgrade. Otherwise, an upgrade to version `0.6.4` is necessary.","status":"published","published":"2024-05-21T14:49:48Z","modified":"2025-12-10T18:49:25.509119Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-401"],"updated_at":"2026-11-02T15:46:36.092962Z"},{"id":"RUSTSEC-2024-0406","title":"BTreeMap memory leak when deallocating nodes with overflows","description":"When storing unbounded types in a `BTreeMap`, a node is represented as a linked list of \"memory chunks\". In some cases, when we deallocate a node only the first memory chunk is deallocated, and the rest of the memory chunks remain (incorrectly) allocated, causing a memory leak.\n\nIn the worst case, depending on how a canister uses the `BTreeMap`, an adversary could interact with the canister through its API and trigger interactions with the map that keep consuming memory due to the memory leak. This could potentially lead to using an excessive amount of memory, or even running out of memory. \n\nThis issue has been fixed in [dfinity/stable-structures/pull/212](https://github.com/dfinity/stable-structures/pull/212) by changing the logic for deallocating nodes to ensure that all of a node's memory chunks are deallocated. Tests have been added to prevent regressions of this nature moving forward.\n\n**Note:** Users of stable-structure \u003c 0.6.0 are not affected.\n\n### Workarounds\nUsers who are not storing unbounded types in `BTreeMap` are not affected and do not need to upgrade. Otherwise, an upgrade to version `0.6.4` is necessary.\n\n### References\n-  [GitHub Security Advisory (GHSA-3rcq-39xp-7xjp)](https://github.com/dfinity/stable-structures/security/advisories/GHSA-3rcq-39xp-7xjp)\n-  [dfinity/stable-structures/pull/212](https://github.com/dfinity/stable-structures/pull/212)\n-  [Stable Structures Documentation](https://docs.rs/ic-stable-structures/0.6.4/ic_stable_structures/)\n-  [Stable Memory on the Internet Computer](https://internetcomputer.org/docs/current/developer-docs/smart-contracts/maintain/storage#stable-memory)","status":"published","published":"2024-05-17T12:00:00Z","modified":"2024-12-04T12:58:50.176116Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:53:39.971022Z"}]}}