Skip to content

Memory leak when calling a canister method via `ic_cdk::call`

High
venkkatesh-sekar published GHSA-rwq6-crjg-9cpw Sep 5, 2024

Package

cargo ic_cdk (Rust)

Affected versions

>= 0.8.0, < 0.8.2
>= 0.9.0, < 0.9.3
>= 0.10.0, < 0.10.1
>= 0.11.0, < 0.11.5
>= 0.12.0, < 0.12.2
>= 0.13.0, < 0.13.4
>= 0.14.0, < 0.14.1
>= 0.15.0, < 0.15.1

Patched versions

0.8.2
0.9.3
0.10.1
0.11.6
0.12.2
0.13.5
0.14.1
0.15.1

Description

When a canister method is called via ic_cdk::call*, a new Future CallFuture is created and can be awaited by the caller to get the execution result. Internally, the state of the Future is tracked and stored in a struct called CallFutureState. A bug in the polling implementation of the CallFuture allows multiple references to be held for this internal state and not all references were dropped before the Future is resolved. Since we have unaccounted references held, a copy of the internal state ended up being persisted in the canister's heap and thus causing a memory leak.

Impact

Canisters built in Rust with ic_cdk and ic_cdk_timers are affected. If these canisters call a canister method, use timers or heartbeat, they will likely leak a small amount of memory on every such operation. In the worst case, this could lead to heap memory exhaustion triggered by an attacker.

Motoko based canisters are not affected by the bug.

Patches

The patch has been backported to all minor versions between >= 0.8.0, <= 0.15.0. The patched versions available are 0.8.2, 0.9.3, 0.10.1, 0.11.6, 0.12.2, 0.13.5, 0.14.1, 0.15.1 and their previous versions have been yanked.

Workarounds

There are no known workarounds at the moment. Developers are recommended to upgrade their canister as soon as possible to the latest available patched version of ic_cdk to avoid running out of Wasm heap memory.

Note

Upgrading the canisters (without updating ic_cdk) also frees the leaked memory but it's only a temporary solution.

References

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CVE ID

CVE-2024-7884

Weaknesses

Credits