heap protection in glibc - some questions

[ge at linuxbox.org (Gadi Evron)]

A friend of mine grabbed my attention to this today. I sent this to 
another list earlier and decided it may be more fitting here on Ken's list.

In version 2.3.4 of glibc...

if (__builtin_expect ((uintptr_t) p > (uintptr_t) -size, 0) ||
__builtin_expect ((uintptr_t) p & MALLOC_ALIGN_MASK, 0))

^^^ This line was added.

There is also a comment on it:

+  /* Little security check which won't hurt performance: the
+     allocator never wrapps around at the end of the address space.
+     Therefore we can exclude some size values which might appear
+     here by accident or by "design" from some intruder.  */
+  if (__builtin_expect ((uintptr_t) p > (uintptr_t) -size, 0)
+      || __builtin_expect ((uintptr_t) p & MALLOC_ALIGN_MASK, 0))
+    {
+      errstr = "free(): invalid pointer";
+    errout:
+      malloc_printerr (check_action, errstr, mem);
+      return;
+    }

It was mentioned on http://www.securityfocus.com/columnists/359.

Now, my questions if some of you can be so kind as to try and answer:
In your estimation, how many people actually heard about this (outside
the tight circle of secure coding maniacs)?

In your estimation, how many people actually go through the pain of
upgrading glibc?

This seems effective to me. In retrospect, how effective did it prove to
be over the past year, in your experience? Is it too early to tell?

Heard of this? http://www.cs.ucsb.edu/~wkr/projects/heap_protection/
What's your take on it, and how do you compare the two?

I'd appreciate your input if you have the time.

A friend of mine might also write on this, but I would like some more
opinions.

Thanks guys!

        Gadi.