Sink boundary: An allocation size is modeled because an attacker-influenced value can change memory consumption.
The pack does not provide a callable signature for this record; the watched access path is shown directly.
| Arg | Access path | Purpose | Watched |
|---|---|---|---|
| Argument[0] | Argument[0] | The access path Atropos marks for this model. | ▲ sink |
CWE-190 ↗
Integer Overflow or Wraparound
A calculation wraps around when the logic assumes the result remains valid.
Attacker's-eye view · alloc-size
A crafted size requests an unexpectedly large allocation, exhausting memory or triggering downstream bounds failures.
// modeled boundary: Argument[0]
calloc(attacker_influenced_value);
1Find the origin of the size.
2Check for an upper bound before allocation.
3Check arithmetic for overflow or wraparound.
These checks require the surrounding codebase. The model names the boundary; it does not decide reachability or prove that a guard dominates every path.
Is this a bug in your code?Atropos stops here — by design
Atropos identifies Argument[0] as a alloc-size sink. It cannot see whether untrusted data reaches this call in your repository.
Lachesis is the codebase-level step: it traces reachability and guards for this symbol.
Check this symbol in Lachesis →Same behavior
●devm_kcallocc●devm_kcallocc●devm_kmalloc_arrayc●devm_kmalloc_arrayc●devm_kmallocc●devm_kzalloccAcross languages
No cross-language match.
What neutralizes it
No sanitizer of this kind is modeled.
Model facts · verbatim from the pack
| Role | Kind | Access path | Model ID | Confidence |
|---|---|---|---|---|
| sink | alloc-size | Argument[0] | c.std.calloc.a0 | medium · corrob. 2 |
| sink | alloc-size | Argument[1] | c.std.calloc.a1 | medium · corrob. 2 |