The fallback implementation of posix_fallocate() in sysdeps/posix/posix_fallocate*.c does a loop over the file, reading a byte, checking that it is zero, and writing it back. If another application is writing to the file at the same time, this can result in random data corruption. One possible solution would be to mmap in the file, then trigger page faults using atomic operations such as gcc's __sync_bool_compare_and_swap; note that this can sometimes put too much pressure on the kernel - I've triggered OOM kills on older linux kernels (2.6.18 xen kernels) this way - and the stat() block count may remain out of date until a sync() call or until the dirty pages pass through the filesystem driver.
The implementation is not menat to be complete. Get a correct kernel if you want functioning programs.
In my opinion, the fallback implementation should not present a data loss possibility - if this is unavoidable, it should return ENOSYS or something instead, and let the application deal with the race condition, since it should know what locks or other synchronization need be used. Would you be open to applying a patch for a mmap-based implementation if I were to provide it?