bugzilla-daemon at netfilter.org
2014-Oct-24 21:58 UTC
[Bug 982] New: vfork() in xtables.c can corrupt stack
https://bugzilla.netfilter.org/show_bug.cgi?id=982 Bug ID: 982 Summary: vfork() in xtables.c can corrupt stack Product: iptables Version: 1.4.x Hardware: x86_64 OS: other Status: NEW Severity: normal Priority: P5 Component: iptables-restore Assignee: netfilter-buglog at lists.netfilter.org Reporter: dan.wilder at watchguard.com Created attachment 451 --> https://bugzilla.netfilter.org/attachment.cgi?id=451&action=edit Move some code to avoid cautions in vfork man page Running iptables-restore on an embedded platform containing no modprobe program, the following lines in xtables.c lead to corrupted stack frame: 357 switch (vfork()) { 358 case 0: 359 argv[0] = (char *)modprobe; 360 argv[1] = (char *)modname; 361 if (quiet) { 362 argv[2] = "-q"; 363 argv[3] = NULL; 364 } else { 365 argv[2] = NULL; 366 argv[3] = NULL; 367 } 368 execv(argv[0], argv); 369 370 /* not usually reached */ 371 exit(1); modprobe pointed to a non-existant program /sbin/modprobe, so execv() always failed. Not a problem in itself on our platform, as the kernel modules are pre-loaded before iptables-restore is run, but it took a bit of headscratching to track this down, as a stack frame was corrupted, leading to failures quite a while after the function containing this code had returned! Relevant caution in man 2 vfork: "The vfork() function has the same effect as fork(2), except that the behavior is undefined if the process created by vfork() either modifies any data ... or calls any other function before successfully calling _exit(2) or one of the exec(3) family of functions." Apparently this has not been a problem for us in earlier versions of glibc, maybe because vfork was more like fork, maybe because the stack corruption was innocuous. Ours is a corner case anyway, as it might not have been a problem had modprobe existed or had modprobe been a symlink to /bin/true. But it seems odd to disregard man page cautions, and our problem goes away if they are heeded. Our solution was move the argv setting up a few lines, just before the vfork, and replace exit() with _exit(). The code reviewer suggested contributing the patch upstream, so please find attached, for whatever it may be worth. -- Dan Wilder -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20141024/5e9b8392/attachment.html>
bugzilla-daemon at netfilter.org
2014-Oct-24 23:00 UTC
[Bug 982] vfork() in xtables.c can corrupt stack
https://bugzilla.netfilter.org/show_bug.cgi?id=982 Florian Westphal <fw at strlen.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |fw at strlen.de Resolution|--- |FIXED --- Comment #1 from Florian Westphal <fw at strlen.de> --- patch applied, thanks! -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20141024/14e32019/attachment.html>
bugzilla-daemon at netfilter.org
2014-Oct-28 20:08 UTC
[Bug 982] vfork() in xtables.c can corrupt stack
https://bugzilla.netfilter.org/show_bug.cgi?id=982 --- Comment #2 from Dan Wilder <dan.wilder at watchguard.com> --- Old versions of iptables-restore affected by same problem, back at least to 1.4.10. Patch is nearly identical. -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20141028/8619e592/attachment.html>
bugzilla-daemon at netfilter.org
2014-Oct-28 20:12 UTC
[Bug 982] vfork() in xtables.c can corrupt stack
https://bugzilla.netfilter.org/show_bug.cgi?id=982 Pablo Neira Ayuso <pablo at netfilter.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pablo at netfilter.org --- Comment #3 from Pablo Neira Ayuso <pablo at netfilter.org> --- We don't maintain old stable versions. So next iptables release will contain this fix. -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20141028/47361a84/attachment.html>