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[1] | Argument[1] | The access path Atropos marks for this model. | ▲ sink |
A calculation wraps around when the logic assumes the result remains valid.
An untrusted size controls allocation without an adequate upper bound.
Resources are allocated without intended limits on size or quantity.
A crafted size requests an unexpectedly large allocation, exhausting memory or triggering downstream bounds failures.
Atropos identifies Argument[1] 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.
| Role | Kind | Access path | Model ID | Confidence |
|---|---|---|---|---|
| sink | alloc-size | Argument[1] | c.kernel.memdup_user_nul.a1 | medium · corrob. 2 |