In C and C++, one may often accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.
Last updated
CWE-468 (Incorrect Pointer Scaling) is a base-level software weakness catalogued by MITRE in the Common Weakness Enumeration (CWE). It describes a recurring type of mistake that can lead to exploitable security vulnerabilities.
4 recorded CVEs are caused by CWE-468 (Incorrect Pointer Scaling). The highest-severity and most recent are shown first. 2 new CWE-468 CVEs have been recorded so far in 2026.
Pointer arithmetic error in SkyFire_548
GPU DDK - UAF read and/or write to arbitrary physical pages in DevmemIntChangeSparse due to incorrect calculation of the virtual index count
What can happen when CWE-468 is exploited.
Read Memory, Modify Memory
Affects: Confidentiality, Integrity
Incorrect pointer scaling will often result in buffer overflow conditions. Confidentiality can be compromised if the weakness is in the context of a buffer over-read or under-read.
Typically introduced during these phases of the software lifecycle.
Languages
Practical mitigations for CWE-468, grouped by where in the lifecycle they apply.
Use a platform with high-level memory abstractions.
Always use array indexing instead of direct pointer manipulation.
Use technologies for preventing buffer overflows.
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.)
Effectiveness: High
Illustrative examples from MITRE showing how the weakness appears in code.
This example attempts to calculate the position of the second byte of a pointer.
Vulnerable example
int *p = x;In this example, second_char is intended to point to the second byte of p. But, adding 1 to p actually adds sizeof(int) to p, giving a result that is incorrect (3 bytes off on 32-bit platforms). If the resulting memory address is read, this could potentially be an information leak. If it is a write, it could be a security-critical write to unauthorized memory-- whether or not it is a buffer overflow. Note that the above code may also be wrong in other ways, particularly in a little endian environment.
Common questions about CWE-468.
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Get alerted the moment a new CWE-468 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.