[uClinux-dev] [PATCH] iptables: use _exit instead of exit if execv fails

2009-03-25 Thread Rainer Keller
Hi All,

We experienced mysterious memory corruptions in our router product
configurations of uClinux. We tracked it down to iptables being the
common element in those scenarios and were able to get a certain
corruption to happen consistently at a fixed address (lucky) and were
able to trap it with a register in our processor that traps on write to
get a backtrace which pointed to this.

When using iptables xtables_insmod is called to load the iptables module
using /sbin/modprobe. Neither the module nor modprobe are currently
installed on our configuration (iptables support is compiled into the
kernel and we use plain insmod currently). So the execv fails:

By using the real `exit' after the failed execv iptables modified memory
(in fact unmapped all the heap) that was still shared between child and
parent. When the child was done the parent continued and tried to free a
pointer from its heap whose backing memory did not exist anymore. So it
clobbered random memory and caused all kinds of havoc.

diff --git a/iptables/xtables.c b/iptables/xtables.c
index a309954..92314bc 100644
--- a/iptables/xtables.c
+++ b/iptables/xtables.c
@@ -134,7 +134,11 @@ int xtables_insmod(const char *modname, const char
*modprob
case 0:
execv(argv[0], argv);
/* not usually reached */
+#ifdef __uClinux__
+   _exit(1);
+#else
exit(1);
+#endif
case -1:
return -1;

This is mine and Ubicom's first patch to uClinux. I hope you find it
useful.

Thank you for creating uClinux!
Best Regards,
- Rainer



___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev


Re: [uClinux-dev] [PATCH] iptables: use _exit instead of exit if execv fails

2009-03-25 Thread David McCullough

Jivin Rainer Keller lays it down ...
 Hi All,
 
 We experienced mysterious memory corruptions in our router product
 configurations of uClinux. We tracked it down to iptables being the
 common element in those scenarios and were able to get a certain
 corruption to happen consistently at a fixed address (lucky) and were
 able to trap it with a register in our processor that traps on write to
 get a backtrace which pointed to this.
 
 When using iptables xtables_insmod is called to load the iptables module
 using /sbin/modprobe. Neither the module nor modprobe are currently
 installed on our configuration (iptables support is compiled into the
 kernel and we use plain insmod currently). So the execv fails:
 
 By using the real `exit' after the failed execv iptables modified memory
 (in fact unmapped all the heap) that was still shared between child and
 parent. When the child was done the parent continued and tried to free a
 pointer from its heap whose backing memory did not exist anymore. So it
 clobbered random memory and caused all kinds of havoc.

Applied :-)

Thanks,
Davidm


 diff --git a/iptables/xtables.c b/iptables/xtables.c
 index a309954..92314bc 100644
 --- a/iptables/xtables.c
 +++ b/iptables/xtables.c
 @@ -134,7 +134,11 @@ int xtables_insmod(const char *modname, const char
 *modprob
 case 0:
 execv(argv[0], argv);
 /* not usually reached */
 +#ifdef __uClinux__
 +   _exit(1);
 +#else
 exit(1);
 +#endif
 case -1:
 return -1;
 
 This is mine and Ubicom's first patch to uClinux. I hope you find it
 useful.
 
 Thank you for creating uClinux!
 Best Regards,
 - Rainer
 
 
 
 ___
 uClinux-dev mailing list
 uClinux-dev@uclinux.org
 http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
 This message was resent by uclinux-dev@uclinux.org
 To unsubscribe see:
 http://mailman.uclinux.org/mailman/options/uclinux-dev
 

-- 
David McCullough,  david_mccullo...@securecomputing.com,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.comhttp://www.uCdot.org
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev