Well, the official fix for mono is in, from the mono team. Guess what ? Mono uses MAP_32BIT if it's available.
>From Linux's mmap manpage: MAP_32BIT (since Linux 2.4.20, 2.6) Put the mapping into the first 2 Gigabytes of the process address space. This flag is only supported on x86-64, for 64-bit programs. It was added to allow thread stacks to be allocated somewhere in the first 2GB of memory, so as to improve context-switch performance on some early 64-bit processors. Modern x86-64 processors no longer have this performance prob- lem, so use of this flag is not required on those systems. The MAP_32BIT flag is ignored when MAP_FIXED is set. >From my point of view, it certainly looks like MAP_32BIT was only put there to address one specific issue in the lifetime of 64 bit platforms, but that some people got some nifty ideas about how to abuse it, and now it's probably there to stay, since software would break without it... And yeah, if MAP_32BIT is not available, you end up in a jungle of #ifdefs... from what I see of the patch, it looks like the problem could affect any 64 bits arch without MAP_32BIT. We're probably just lucky to hit it first. Let's stress out how MAP_32BIT is not such a good idea, since you constrain the allocations into a much smaller address space, thus less random addresses, more opportunities for buffer overflow to be exploited. (but hey, we all know that buffer overflows don't ever happen under Linux, which is why they don't need no shoddy strlcpy). Differing opinions are welcome, but please, can you try to back it up with facts ?