CWE-1102, Reliance on Machine-Dependent Data Representation, describes code that uses a data representation relying on low level constructs that may vary across processors, physical machines, operating systems or other physical components.
MITRE allows this entry for mapping real vulnerabilities, with careful reading of its description.
How it happens
Low level details look fixed on the machine you develop on, and are not. The size of long, the byte order of integers, struct padding and the size of file offsets all change between platforms or build settings.
/* Vulnerable pattern: assumes int is 4 bytes and little endian */
struct Header {
int length;
int type;
};
void parse(const unsigned char* raw) {
struct Header h;
memcpy(&h, raw, sizeof(h)); /* layout and byte order depend on the machine */
/* h.length is then trusted */
}
On another platform the same bytes produce a different length. If that length is later used to size a copy, the mismatch can cause out of bounds access.
/* Fix: parse each field explicitly with fixed width types */
#include <stdint.h>
uint32_t read_u32_le(const unsigned char* p) {
return (uint32_t)p[0] | ((uint32_t)p[1] << 8)
| ((uint32_t)p[2] << 16) | ((uint32_t)p[3] << 24);
}
void parse(const unsigned char* raw, size_t raw_len) {
if (raw_len < 8) return;
uint32_t length = read_u32_le(raw);
uint32_t type = read_u32_le(raw + 4);
/* validate length against raw_len before use */
}
What an attacker gains
MITRE lists reduced maintainability and portability, with the indirect effect of making vulnerabilities harder to find and fix. The record also cites a real case: CVE-2025-47153, described as a chain in which the build process for a JavaScript runtime environment can have inconsistent sizes for off_t (CWE-1102), allowing out of bounds access and a segmentation fault (CWE-119).
The lesson from that description is that two parts of a build can disagree about a basic size, and the disagreement shows up as a memory safety bug.
How to find it
The record lists no detection methods, so use general ones.
- Search for casts of structs to byte buffers, raw
memcpyinto structs, and use of plainintorlongin file and network formats. - Build and test on every platform you ship, including 32 bit and big endian if relevant.
- Compile with warnings for conversions and sign changes.
- Check that every compilation unit sees the same type sizes and feature flags.
How to fix it
- Use fixed width types such as
uint32_tfor anything stored or sent. - Serialize and parse field by field, with explicit byte order.
- Validate every length against the real buffer size.
- Keep build flags consistent across all parts of a build.
- Run tests on each target architecture in CI.
Quick check
Why is copying bytes straight into a struct risky?
Padding, field sizes and byte order differ across platforms, so the same bytes can produce different values and bad lengths.
What does the cited CVE description show?
Inconsistent sizes of a basic type within one build, which led to out of bounds access.
