The code calls sizeof() on a pointer type, which can be an incorrect calculation if the programmer intended to determine the size of the data that is being pointed to.
The use of sizeof() on a pointer can sometimes generate useful information. An obvious case is to find out the wordsize on a platform. More often than not, the appearance of sizeof(pointer) indicates a bug.

Primary

Implementation

High

Integrity
Confidentiality
Modify Memory
Read Memory
This error can often cause one to allocate a buffer that is much smaller than what is needed, leading to resultant weaknesses such as buffer overflows.

Automated Static Analysis
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.)
High

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.

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.
In this example, sizeof(foo) returns the size of the pointer.

double *foo;...foo = (double *)malloc(sizeof(foo));

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));

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.

/* Ignore CWE-259 (hard-coded password) and CWE-309 (use of password system for authentication) for this example. */

char *username = "admin";char *pass = "password";
int AuthenticateUser(char *inUser, char *inPass) {
printf("Sizeof username = %d\n", sizeof(username));printf("Sizeof pass = %d\n", sizeof(pass));
if (strncmp(username, inUser, sizeof(username))) {printf("Auth failure of username using sizeof\n");return(AUTH_FAIL);}
/* Because of CWE-467, the sizeof returns 4 on many platforms and architectures. */

if (! strncmp(pass, inPass, sizeof(pass))) {printf("Auth success of password using sizeof\n");return(AUTH_SUCCESS);}else {printf("Auth fail of password using sizeof\n");return(AUTH_FAIL);}
}
int main (int argc, char **argv){
int authResult;
if (argc < 3) {ExitError("Usage: Provide a username and password");}authResult = AuthenticateUser(argv[1], argv[2]);if (authResult != AUTH_SUCCESS) {ExitError("Authentication failed");}else {DoAuthenticatedTask(argv[1]);}
}

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).
Because of the partial comparison, any of these passwords would still cause authentication to succeed for the "admin" user:

pass5passABCDEFGHpassWORD

Because only 4 characters are checked, this significantly reduces the search space for an attacker, making brute force attacks more feasible.
The same problem also applies to the username, so values such as "adminXYZ" and "administrator" will succeed for the username.

Use of sizeof() on a pointer type

ARR01-C
Do not apply the sizeof operator to a pointer when taking the size of an array

MEM35-C
Allocate sufficient memory for an object
CWE More Abstract

SFP10
Incorrect Buffer Length Computation

Allowed
This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

CLASP
2006-07-19
Draft 3
2006-07-19

Eric Dalci
Cigital
2008-07-01
updated Time_of_Introduction

KDM Analytics
2008-08-01
added/updated white box definitions

CWE Content Team
MITRE
2008-09-08
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities

CWE Content Team
MITRE
2008-11-24
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2009-03-10
updated Demonstrative_Examples

CWE Content Team
MITRE
2009-12-28
updated Demonstrative_Examples

CWE Content Team
MITRE
2010-02-16
updated Relationships

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2011-06-27
updated Common_Consequences

CWE Content Team
MITRE
2011-09-13
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2012-05-11
updated Relationships

CWE Content Team
MITRE
2014-06-23
updated Description, Other_Notes

CWE Content Team
MITRE
2014-07-30
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2017-11-08
updated Demonstrative_Examples, Taxonomy_Mappings, White_Box_Definitions

CWE Content Team
MITRE
2019-01-03
updated Relationships

CWE Content Team
MITRE
2020-02-24
updated References

CWE Content Team
MITRE
2023-04-27
updated Detection_Factors, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2024-11-19
4.16
2024-11-19
updated Description

CWE Content Team
MITRE
2025-04-03
4.17
2025-04-03
updated Demonstrative_Examples

Marco Trosi
Schaeffler Group
2024-10-21
4.16
2024-11-19
Identified inappropriate emphasis on pointers to data allocated with malloc(), leading to a description change.