bugtraq - Re: gcc 4.1 bug miscompiles pointer range checks, may place you at risk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87u08qu22q.fsf@mid.deneb.enyo.de>
Date: Tue, 18 Apr 2006 21:16:13 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Felix von Leitner <felix-bugtraq@...e.de>
Cc: bugtraq@...urityfocus.com
Subject: Re: gcc 4.1 bug miscompiles pointer range checks, may place you at risk

* Felix von Leitner:

> static inline int range_ptrinbuf(const void* buf,unsigned long len,const void* ptr) {
>   register const char* c=(const char*)buf;      /* no pointer arithmetic on void* */
>   return (c && c+len>c && (const char*)ptr-c<len);
> }

It seems that the problem is that

  c + len > c

is equivalent to

  len != 0.

Either c + len is within the same object c points to, and it's value
is larger than c (provided that len is not zero), or c + len is
undefined (because it's not the same object).  In the latter case, the
outcome is not specified by the C standard (or the GCC documentation),
so it's permissible to choose len != 0 as the value, too.

I wouldn't rule out a compiler bug in this area, but the test case is
invalid.