Skip to end of metadata
Go to start of metadata

Modifying a variable through a pointer of an incompatible type (other than unsigned char) can lead to unpredictable results. Subclause 6.2.7 of the C Standard states that two types may be distinct yet compatible and addresses precisely when two distinct types are compatible.

This problem is often caused by a violation of aliasing rules. The C Standard, 6.5, paragraph 7 [ISO/IEC 9899:2011], specifies those circumstances in which an object may or may not be aliased.

An object shall have its stored value accessed only by an lvalue expression that has one of the following types:

  • a type compatible with the effective type of the object,
  • a qualified version of a type compatible with the effective type of the object,
  • a type that is the signed or unsigned type corresponding to the effective type of the object,
  • a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object,
  • an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or
  • a character type.

Noncompliant Code Example

In this noncompliant example, an object of type float is incremented through an int *. The programmer can use the unit in the last place to get the next representable value for a floating-point type.  However, accessing an object through a pointer of an incompatible type is undefined behavior.

#include <stdio.h>
 
void f(void) {
  if (sizeof(int) == sizeof(float)) {
    float f = 0.0f;
    int *ip = (int *)&f;
    (*ip)++;
    printf("float is %f\n", f);
  }
}

Compliant Solution

In this compliant solution, the standard C function nextafterf() is used to round toward the highest representable floating-point value:

#include <float.h>
#include <math.h>
#include <stdio.h>
 
void f(void) {
  float f = 0.0f;
  f = nextafterf(f, FLT_MAX);
  printf("float is %f\n", f);
}

Noncompliant Code Example

In this noncompliant code example, an array of two values of type short is treated as an integer and assigned an integer value. The resulting values are indeterminate.

#include <stdio.h>
 
void func(void) {
  short a[2];
  a[0]=0x1111;
  a[1]=0x1111;

  *(int *)a = 0x22222222;

  printf("%x %x\n", a[0], a[1]);
}

When translating this code, an implementation can assume that no access through an integer pointer can change the array a, consisting of shorts. Consequently, printf() may be called with the original values of a[0] and a[1].

Implementation Details

Recent versions of GCC turn on the option -fstrict-aliasing, which allows alias-based optimizations, by default with -O2. Some architectures then print "1111 1111" as a result. Without optimization, the executable generates the expected output "2222 2222."

To disable optimizations based on alias analysis for faulty legacy code, the option -fno-strict-aliasing can be used as a workaround. The option -Wstrict-aliasing, which is included in -Wall, warns about some, but not all, violations of aliasing rules when -fstrict-aliasing is active.

When GCC 3.4.6 compiles this code with optimization, the assignment through the aliased pointer is effectively eliminated.

Compliant Solution

This compliant solution uses a union type that includes a type compatible with the effective type of the object:

#include <stdio.h>
 
void func(void) {
  union {
    short a[2];
    int i;
  } u;

  u.a[0]=0x1111;
  u.a[1]=0x1111;
  u.i = 0x22222222;

  printf("%x %x\n", u.a[0], u.a[1]);

  /* ... */
}

The printf() behavior in this compliant solution is unspecified, but it is commonly accepted as an implementation extension. (See unspecified behavior 11.)

This function typically outputs "2222 2222." However, there is no guarantee that this will be true, even on implementations that defined the unspecified behavior; values of type short need not have the same representation as values of type int.

Noncompliant Code Example

In this noncompliant code example, a gadget object is allocated, then realloc() is called to create a widget object using the memory from the gadget object. Although reusing memory to change types is acceptable, accessing the memory copied from the original object is undefined behavior.

#include <stdlib.h>
 
struct gadget {
  int i;
  double d;
  char *p;
};
 
struct widget {
  char *q;
  int j;
  double e;
};
 
void func(void) {
  struct gadget *gp;
  struct widget *wp;
 
  gp = (struct gadget *)malloc(sizeof(struct gadget));
  if (!gp) {
    /* Handle error */
  }
  /* ... Initialize gadget ... */
  wp = (struct widget *)realloc(gp, sizeof(struct widget));
  if (!wp) {
    free(gp);
    /* Handle error */
  }
  if (wp->j == 12) {
    /* ... */
  }
  /* ... */
  free(wp);
}

Compliant Solution

This compliant solution reuses the memory from the gadget object but reinitializes the memory to a consistent state before reading from it:

#include <stdlib.h>
#include <string.h>
 
struct gadget {
  int i;
  double d;
  char *p;
};
 
struct widget {
  char *q;
  int j;
  double e;
};
 
void func(void) {
  struct gadget *gp;
  struct widget *wp;
 
  gp = (struct gadget *)malloc(sizeof (struct gadget));
  if (!gp) {
    /* Handle error */
  }
  /* ... */
  wp = (struct widget *)realloc(gp, sizeof(struct widget));
  if (!wp) {
    free(gp);
    /* Handle error */
  }
  memset(wp, 0, sizeof(struct widget));
  /* ... Initialize widget ... */

  if (wp->j == 12) {
    /* ... */
  }
  /* ... */
  free(wp);
}

Noncompliant Code Example

According to the C Standard, 6.7.6.2 [ISO/IEC 9899:2011], using two or more incompatible arrays in an expression is undefined behavior. (See also undefined behavior 76.)

For two array types to be compatible, both should have compatible underlying element types, and both size specifiers should have the same constant value. If either of these properties is violated, the resulting behavior is undefined.

In this noncompliant code example, the two arrays a and b fail to satisfy the equal size specifier criterion for array compatibility. Because a and b are not equal, writing to what is believed to be a valid member of a might exceed its defined memory boundary, resulting in an arbitrary memory overwrite.

enum { ROWS = 10, COLS = 15 };
 
void func(void) {
  int a[ROWS][COLS];
  int (*b)[ROWS] = a;
}

Most compilers will produce a warning diagnostic if the two array types used in an expression are incompatible.

Compliant Solution

In this compliant solution, b is declared to point to an array with the same number of elements as a, satisfying the size specifier criterion for array compatibility:

enum { ROWS = 10, COLS = 15 };
 
void func(void) {
  int a[ROWS][COLS];
  int (*b)[COLS] = a;
}

Risk Assessment

Optimizing for performance can lead to aliasing errors that can be quite difficult to detect. Furthermore, as in the preceding example, unexpected results can lead to buffer overflow attacks, bypassing security checks, or unexpected execution.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

EXP39-C

Medium

Unlikely

High

P2

L3

Automated Detection

Tool

Version

Checker

Description

LDRA tool suite
9.7.1
94 S, 554 SPartially implemented
Parasoft C/C++test

10.4.1

CERT_C-EXP39-a
CERT_C-EXP39-b
CERT_C-EXP39-c
CERT_C-EXP39-d
CERT_C-EXP39-e
CERT_C-EXP39-f

There shall be no implicit conversions from integral to floating type
A cast should not be performed between a pointer to object type and a different pointer to object type
Avoid accessing arrays and pointers out of bounds
Avoid buffer overflow from tainted data due to defining incorrect format limits
Avoid buffer read overflow from tainted data
Avoid buffer write overflow from tainted data

Polyspace Bug Finder

R2018a

Pointer access out of bounds

Unreliable cast of pointer

MISRA C:2012 Rule 11.3

Pointer dereferenced outside its bounds

Pointer implicitly cast to different data type

A cast shall not be performed between a pointer to object type and a pointer to a different object type

PRQA QA-C
9.5

0310, 0751, 3305

Partially implemented
PRQA QA-C++

4.3

3017, 3030, 3033 
PVS-Studio

6.23

V580

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Key here (explains table format and definitions)

Taxonomy

Taxonomy item

Relationship

ISO/IEC TS 17961Accessing an object through a pointer to an incompatible type [ptrcomp]Prior to 2018-01-12: CERT: Unspecified Relationship
CWE 2.11CWE-119, Improper Restriction of Operations within the Bounds of a Memory Buffer2017-05-18: CERT: Partial overlap
CWE 2.11CWE-125, Out-of-bounds Read2017-05-18: CERT: Partial overlap
CWE 2.11CWE-7042017-06-14: CERT: Rule subset of CWE

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-119 and EXP39-C

Independent( ARR30-C, ARR38-C, ARR32-C, INT30-C, INT31-C, EXP39-C, EXP33-C, FIO37-C) STR31-C = Subset( Union( ARR30-C, ARR38-C)) STR32-C = Subset( ARR38-C)

Intersection( EXP39-C, CWE-119) =


  • Reading memory assigned to one type, but being accessed through a pointer to a larger type.


EXP39-C – CWE-119 =


  • Writing to memory assigned to one type, but accessed through a pointer to a larger type



  • Reading memory assigned to one type, but being accessed through a pointer to a smaller (or equal-sized) type


CWE-119 – EXP39-C =


  • Reading beyond a buffer using a means other than accessing a variable through an incompatible pointer.


CWE-123 and EXP39-C

Intersection( CWE-123, EXP39-C) = Ø

EXP39-C allows overflowing a (small) buffer, but not arbitrary memory writes. (Possibly an arbitrary-memory write exploit could be devised using a “perfect storm” of incompatible types, but this would be uncommon in practice.)

CWE-125 and EXP39-C

Independent( ARR30-C, ARR38-C, EXP39-C, INT30-C) STR31-C = Subset( Union( ARR30-C, ARR38-C)) STR32-C = Subset( ARR38-C)

Intersection( EXP39-C, CWE-125) =


  • Reading memory assigned to one type, but being accessed through a pointer to a larger type.


ESP39-C – CWE-125 =


  • Reading memory assigned to one type, but being accessed through a pointer to a smaller (or equal-sized) type


CWE-125 – EXP39-C =


  • Reading beyond a buffer using a means other than accessing a variable through an incompatible pointer.


CWE-188 and EXP39-C

Intersection( CWE-188, EXP39-C) = Ø

CWE-188 appears to be about making assumptions about the layout of memory between distinct variables (that are not part of a larger struct or array). Such assumptions typically involve pointer arithmetic (which violates ARR30-C). EXP39-C involves only one object in memory being (incorrectly) interpreted as if it were another object. EG a float being treated as an int (usually via pointers and typecasting)

CWE-704 and EXP39-C

CWE-704 = Union( EXP39-C, list) where list =


  • Incorrect (?) typecast that is not incompatible


Bibliography

[Acton 2006]"Understanding Strict Aliasing"
GCC Known Bugs"C Bugs, Aliasing Issues while Casting to Incompatible Types"
[ISO/IEC 9899:2011]6.5, "Expressions"
6.7.6.2, "Array Declarators"
[Walfridsson 2003]Aliasing, Pointer Casts and GCC 3.3



15 Comments

  1. Submitted by email from John Engelhart:

    Specifically, the example at the end of the page designated as the "Compliant Solution" (reproduced here)

    Compliant Solution

    This compliant solution uses a union type that includes a type compatible with the effective type of the object.

    union {
      short a[2];
      int i;
    } u;
    
    u.a[0]=0x1111;
    u.a[1]=0x1111;
    
    u.i = 0x22222222;
    
    printf("%x %x\n", u.a[0], u.a[1]);
    

    This code example now reliably outputs "2222 2222".
    ------------------

    In fact, this is an example of "undefined behavior" and should be removed.
    From "The New C Standard" ( http://www.knosof.co.uk/cbook/cbook.html ) page ~960 (covering C99 Section 6.5 clause 7 "An object shall have its stored value accessed only by an lvalue expression that has one of the following types:" (the same rules quoted at the top of EXP39-C):

    Commentary

    This list is sometimes known as the aliasing rules for C. Any access to the

    stored value of an object using a type that is not one of those listed next

    results in undefined behavior. To access the same object using one of the different types listed requires the use of a pointer type. Reading from a different member of a union type than the one last stored into is unspecified behavior.
    ------------------

    Note the last sentence. Reading from a different member of a union other than the last one used to store a value is unspecified behavior. Clearly the example given as "Compliant" in EXP39-C is reading from different members (u.a0 and u.a1) than the one last stored (u.i = ...). This example /WILL NOT/ reliably output "2222 2222".

    Type punning like this is very difficult to do "correctly". IMHO, any form of type punning should be strongly discouraged, and no examples of how to do it "correctly" should be given.:

    1. I agree with the sentiment...type punning is not something we want to encourage. OTOH we can't exactly show a compliant solution without it.

      Still, the 1st CS doesn't define what the "expected value" is. On my platform f() returns 0...is that the expected value??? The 2nd CS also has an implicit assumption that sizeof(int) == 2 * sizeof(short).

      I suspect a good CS can be made involving any type T and an array of: char[ sizeof(T)]. By 'good', I don't mean 'recommended', I only mean 'well-defined'. I think its a mistake to even refer to 'expected values' when doing type-punning.

  2. In the 2nd CS, what is the 'expected value'? And what is type-punning? (that is, if the rule is going to use 'type-punning' in a legit context, it needs to cite a definition.
    On my Ubuntu box, this CS (and the corresponding NCCEs) print 0...is that the expected value? Or is it 3?

    1. The expected value is unspecified because the underlying representation of a double is unspecified.  So whatever random bits happen to be there appears to be what's "expected."

      Also, I agree we should have a formal definition for type punning.  But I would prefer we simply didn't use the terminology or the example in our rules as it's an evil concept, even if valid in C.

      1. It sounds like you agree with me that the compliant solution isn't really compliant.

        I'm nuking the NCCE & CS pair on Monday unless someone steps in to save it.

        1. I neither agree nor disagree.  (wink)  The code, as it stands, is useless without further explanation of programmer intent.  However, the code could be valid depending on that intent as there is no UB.

          Don't consider this to be "stepping in to save" the examples though, just clarifying why I didn't chop them when I reviewed.

          1. Nuked those code samples, approved the rule.

  3. the gadget example is not encapsulated in a function of any kind; this probably needs to be fixed.

  4. Newbie here... first comment on the site.  So bear with me.  How did P18/L1 MEM08-C become depracated by this rule (EXP39-C) which is P2/L3?

    John Whited, CISSP, CSSLP

    Principal Security Engineer

    Raytheon IIS Garland TX

    1. The rationale for the deprecation was that MEM08-C's underlying problem (realloc'ing something other than an array) is the same problem as EXP39-C's: don't access a pointer through an incompatible type, because the realloc needs to copy data from the original object. So if the original objects are not compatible, you get UB.

      I think MEM08-C's priority was a bit on the high side (I think I would have ranked it about a P4-P6), and perhaps EXP39-C's priority may be a bit low with this addition.

      1. Agreed.  One note though...the priorities are directly derived from the Severity, Liklihood, and Remediation Cost metrics. See How this Coding Standard is Organized for more info.

        1. If there's a better place for this discussion let me know.  But has there been any discussion about harmonizing SEI CERT Priority / Level with MITRE's CWRAF / CWSS and/or OWASP prioritization techniques?  There are pluses and minuses to each I'm sure. But the Priority / Level approach lacks the ability to factor in software operational factors such as business / mission impact, technology in use (OS, language, etc.) and operational environment (web app vs. embedded systems etc.).

          1. maybe email?  we haven't looked at any of these.  I think we've had our system for about 10 years now;  I'm not sure when these other systems came about.  I'm pretty happy about not factoring in business / mission impact, etc.  The assignments we have made for criticality, likelihood, and remediation cost are meant to be independent of all of this, but may serve as input into such metrics. 

  5. Gadget/Widget example is error prone. gp and wp in most cases point at the same location. In worst case gp will be point at freed area (when re-allocation doesn't append memory, but allocates it in a different area).  

    1. It is important to not touch gp after the realloc() call, because its memory has either been freed, or it points to the same chunk as wp.  I added code to free wp when it is no longer in use.

      Freeing gp if realloc() returns NULL is perfectly fine in this case, and necessary when doing normal cleanup.