Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
CWE-467 Variant Draft
Use of sizeof() on a Pointer Type
This vulnerability occurs when a developer uses the sizeof() operator on a pointer variable instead of the data it points to, leading to incorrect size calculations and potential buffer overflows or…
Definition
What is CWE-467?
This vulnerability occurs when a developer uses the sizeof() operator on a pointer variable instead of the data it points to, leading to incorrect size calculations and potential buffer overflows or underflows.
Using sizeof() on a pointer returns the size of the pointer itself (e.g., 4 or 8 bytes for the memory address), not the size of the allocated object or data structure it references. This is a common mistake when programmers intend to calculate buffer sizes, perform memory operations like memcpy, or allocate dynamic memory, resulting in calculations that are off by a factor of the pointer size.
While sizeof(pointer) can be intentionally used for platform-specific code (like determining system word size), its presence usually indicates a logic bug. To avoid this, always ensure sizeof() is applied to the dereferenced pointer type (e.g., sizeof(*pointer)) or the actual data type name, especially when dealing with arrays, structs, or dynamically allocated memory blocks.
Real-world impact
Real-world CVEs caused by CWE-467
No public CVE references are linked to this CWE in MITRE's catalog yet.
How attackers exploit it
Step-by-step attacker path
- 1
Care should be taken to ensure sizeof returns the size of the data structure itself, and not the size of the pointer to the data structure.
- 2
In this example, sizeof(foo) returns the size of the pointer.
- 3
In this example, sizeof(*foo) returns the size of the data structure and not the size of the pointer.
- 4
This example defines a fixed username and password. The AuthenticateUser() function is intended to accept a username and a password from an untrusted user, and check to ensure that it matches the username and password. If the username and password match, AuthenticateUser() is intended to indicate that authentication succeeded.
- 5
In AuthenticateUser(), because sizeof() is applied to a parameter with an array type, the sizeof() call might return 4 on many modern architectures. As a result, the strncmp() call only checks the first four characters of the input password, resulting in a partial comparison (CWE-187), leading to improper authentication (CWE-287).
Vulnerable code example
Vulnerable C
In this example, sizeof(foo) returns the size of the pointer.
double *foo;
...
foo = (double *)malloc(sizeof(foo)); Attacker payload
Because of the partial comparison, any of these passwords would still cause authentication to succeed for the "admin" user:
pass5
passABCDEFGH
passWORD Secure code example
Secure C
In this example, sizeof(*foo) returns the size of the data structure and not the size of the pointer.
double *foo;
...
foo = (double *)malloc(sizeof(*foo)); What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-467
- Implementation Use expressions such as "sizeof(*pointer)" instead of "sizeof(pointer)", unless you intend to run sizeof() on a pointer type to gain some platform independence or if you are allocating a variable on the stack.
Detection signals
How to detect CWE-467
CWE-467
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Frequently asked questions What is CWE-467?
How serious is CWE-467?
What languages or platforms are affected by CWE-467?
How can I prevent CWE-467?
How does Plexicus detect and fix CWE-467?
Where can I learn more about CWE-467?
Frequently asked questions
What is CWE-467?
This vulnerability occurs when a developer uses the sizeof() operator on a pointer variable instead of the data it points to, leading to incorrect size calculations and potential buffer overflows or underflows.
How serious is CWE-467?
MITRE rates the likelihood of exploit as High — this weakness is actively exploited in the wild and should be prioritized for remediation.
What languages or platforms are affected by CWE-467?
MITRE lists the following affected platforms: C, C++.
How can I prevent CWE-467?
Use expressions such as "sizeof(*pointer)" instead of "sizeof(pointer)", unless you intend to run sizeof() on a pointer type to gain some platform independence or if you are allocating a variable on the stack.
How does Plexicus detect and fix CWE-467?
Plexicus's SAST engine matches the data-flow signature for CWE-467 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-467?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/467.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-467
Resources
Further reading
- MITRE — official CWE-467 https://cwe.mitre.org/data/definitions/467.html
- The CLASP Application Security Process https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf
- EXP01-A. Do not take the sizeof a pointer to determine the size of a type https://www.securecoding.cert.org/confluence/display/seccode/EXP01-A.+Do+not+take+the+sizeof+a+pointer+to+determine+the+size+of+a+type
Ready to validate what matters?
Ready to validate what matters?
Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.