You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 64 Next »

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 mentions 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, subclause 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.

Accessing an object by means of any other lvalue expression (other than unsigned char) results in undefined behavior. See undefined behavior 34 in Annex J of the C Standard.

Noncompliant Code Example

In this noncompliant example, an object of type float is incremented through an int *. Using the maximum units in last position is often done as a way to get the next representable value for a floating-point number. However, accessing an object through a pointer of incompatible types is undefined behavior.

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

Compliant Solution

In this compliant solution, the standard C function nextafterf() is used to round towards 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

This noncompliant code example attempts to read from a different union member than the one most recently written to, which is known as type-punning.

union a_union {
  int i;
  double d;
};

int f(void) {
  union a_union t;
  int *ip;
  t.d = 3.0;
  ip = &t.i;
  return *ip;
}

However, instead of taking the address of the most-recently written member of the union, the code takes the address of a member that has not been written to. The compiler may determine that ip refers to some value other than the value stored by t.i and return a value other than the expected value.

Noncompliant Code Example

In this noncompliant code example, access by taking the address, casting the resulting pointer, and dereferencing the result has undefined behavior even if the cast uses a union type:

union a_union {
  int i;
  double d;
};

int f(void) {
  double d = 3.0;
  return ((union a_union *)&d)->i;
}

Because of optimization, the function f() may return something other than the expected value.

Compliant Solution

Type-punning is allowed provided the memory is accessed through the union type. This compliant solution returns the expected value:

union a_union {
  int i;
  double d;
};
          
int f(void) {
  union a_union t;
  t.d = 3.0;
  return t.i;
} 

Noncompliant Code Example

In this noncompliant code example, an array of two shorts is treated as an integer and assigned an integer value. The resulting value of the two shorts is undefined.

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

  /* ... */
}

This code example now reliably outputs "2222 2222."

Noncompliant Code Example

In this 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;
};
 
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 */
}
if (wp->j == 12) {
  /* ... */
}

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;
};
 
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));
if (wp->j == 12) {
  /* ... */
}

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 and/or bypassing security checks and/or unexpected execution.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

EXP39-C

Medium

Unlikely

High

P2

L3

Automated Detection

Tool

Version

Checker

Description

PRQA QA-C
Unable to render {include} The included page could not be found.

0310
3305

Partially implemented

Related Vulnerabilities

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

Related Guidelines

ISO/IEC TS 17961Accessing an object through a pointer to an incompatible type [ptrcomp]

Bibliography

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

 


 

 

  • No labels