I have few boxes around with different OSes/distros and try to use them in reasonable manner. For a some time I contemplated setting up continuous integration for OpenEmbedded, and the box suiting that purpose runs FC5 here.
Well, soon after running a test build on it, I hit issue that OE's binary locale generation, done by running target localedef under QEMU "user" emulation (qemu-arm) errors out there, and on closer inspection, just segfaults. Taking some time to run it thru gdb and strace, I found that it happens after mmap2() syscall, and in seemingly random places in code. More close look at the stuff showed that address parameter to faulty mmap() kind of correlates with VDSO location reported by gdb. Gotcha! So, somehow guest process manages to overwrite VDSO as used on FC5 system.
Now it took some time to figure out what's happening, but it turned out that FC5 applies whole bunch of patches (mostly labelled "execshield" and "xen") affecting VDSO handling to 2.6.15 kernel, when final set of VDSO randomization patches, etc. was not yet in mainline. In other words, FC developer took their own try on solving VDSO issues, with the outcome described above.
Well, it took only couple hours more to rebuild kernel without those patches and teaching it to pickup original initrd (maybe I should have rebuilt it instead, I just didn't do that before). And now I have pristine and full-feature OE builds on FC5 system, voila! ;-)