A stack frame overflow flaw was found in the glibc's clntudp_call(). A malicious server could use this flaw to flood a connecting client application with ICMP and UDP packets, triggering the stack overflow and resulting in a crash. clntudp_call() contains an alloca call in a loop, which causes it to consume very large amounts of stack space. The same faulty code is also present in the libtirpc library.
Acknowledgments: Name: Aldy Hernandez (Red Hat)
Created libtirpc tracking bugs for this issue: Affects: fedora-all [bug 1337142]
Created glibc tracking bugs for this issue: Affects: fedora-all [bug 1337140]
Created attachment 1158765 [details] CVE-2016-4429 patch
As per upstream: On Red Hat Enterprise Linux 6: No looping behaviour was observed because the error state on the socket appears to be sticky, so the second recvmsg (with MSG_DONTWAIT, after the one with MSG_ERRQUEUE) in clntudp_call does not fail with EWOULDBLOCK, and the function returns to the caller. Without the looping behavior, the alloca should be harmless for pretty much all applications because the size argument depends on the size of the generated (outgoing) UDP packet and will be well below default stack sizes. Therefore it is not affected by this flaw. On Red Hat Enterprise Linux 7: Looping behaviour was observed and segfaults with small stack sizes. -fstack-class-protection will turn this into a reliable crash (no code execution possible). Even without that build flag, this will not be exploitable in most cases because the application determines the alloca argument, based on the generated UDP packet (not the response). This will usually be smaller than a page. The maximum impact is therefore crash, there is no code execution involved. This issue was fixed in glibc-2.23.1, therefore Red Hat Enterprise Linux 8 is not affected by this flaw.
Public reproducer is available at: https://sourceware.org/bugzilla/attachment.cgi?id=12624
Statement: Based on technical analysis of this flaw: On Red Hat Enterprise Linux 6: No looping behaviour was observed. Without the looping behavior, the alloca should be harmless for pretty much all applications because the size argument depends on the size of the generated (outgoing) UDP packet and will be well below default stack sizes. Therefore it is not affected by this flaw. On Red Hat Enterprise Linux 7: Looping behaviour was observed and segfaults with small stack sizes. -fstack-class-protection will turn this into a reliable crash (no code execution possible). Even without that build flag, this will not be exploitable in most cases because the application determines the alloca argument, based on the generated UDP packet (not the response). This will usually be smaller than a page. The maximum impact is therefore crash, there is no code execution involved. This issue was fixed in glibc-2.23.1, therefore Red Hat Enterprise Linux 8 is not affected by this flaw.