You've got all sorts of misapprehensions about this.
Firstly what you seem to be proposing is that somehow this ABI bug would corrupt the OS
kernel. I can assure you that this cannot happen. Linux* couldn't care two hoots about the DF
bit in the flag register of a userspace process which is all that's being tweaked. However the
process itself might care, and is entitled to ABI correct behaviour - and so Linux needed to
be patched to reset this flag bit when calling the signal handler in the userspace process.
Flipping the DF bit is not a privileged operation, it's a normal function of the x86 processor
family. You can add code to your programs to arbitrarily flip DF if you like, and at most
you'll just manage to make it hang or crash.
To have a security problem, what would be needed is to run privileged code which relies on
this ABI feature, and then send it signals until it malfunctions. In most cases on Linux your
privileged code was compiled with GCC < 4.3 and thus does not rely on this ABI feature. Code
from vendors compiled with a patched GCC 4.3.x will also not be affected. Daemons and other
privileged processes very rarely provide a mechanism to receive signals from unprivileged
users. Most of them do very little in their signal handlers and thus won't be relying on this
ABI feature even with GCC 4.3.0. So you need a very extraordinary set of circumstances to
achieve anything more than crashing your own programs.
The code in which this bug was originally noticed deliberately causes large numbers of
SIGSEGVs during normal operation and handles them by AFAICT calling memmove() from an assembly
language routine. Does that sound like any of the programs running with privileges on your
servers? No, didn't think so.
If you're in the habit of running code created by untrusted users then you don't need this ABI
bug to have problems, indeed it makes no difference at all - you've got a gaping hole in your
security strategy from the start.
* Read NetBSD, FreeBSD, OpenBSD etc. for Linux as you prefer. They all seem to have an
identical bug here, shielded by GCC