Description of problem: The second part of the patch introduced in #131848 is bogous, more than that, it introduce a real bug: diff -ur iptables-1.2.11.orig/extensions/libipt_rpc.c iptables-1.2.11/extensions/libipt_rpc.c --- iptables-1.2.11.orig/extensions/libipt_rpc.c 2004-09-05 11:27:50.000000000 -0400 +++ iptables-1.2.11/extensions/libipt_rpc.c 2004-09-05 11:41:11.000000000 -0400 @@ -252,7 +252,7 @@ idup = 0; memset(buf, 0, sizeof(buf)); - dst = (char *)buf - 1; + dst = (char *)buf; } } After dst = buf -1; dst is pointing to invalid memory, but there is a dst++ in the for()-head before really accessing *dst -> no problem. *with* this patch, we're accessing buf from [1] not from [0] when filling the second parameter. But we're always parsing the buf from [0], and thus reading invalid data. Version-Release number of selected component (if applicable): FC4 / iptables-1.3.0-2 (*really* tested with trustix 3.0 / iptables-1.3.3-2tr, while auditing the iptables patches, which are the same as in FC4 package) How reproducible: everytime Steps to Reproduce: apply attached iptables-debug.patch to see the parsing results without the need of a ipt_rpc.ko patched kernel. (The "No chain/target/match by that name" errors came from kernel without a ipt_rpc.ko) Actual results with bogous patch: $ iptables -A INPUT -m rpc --rpcs mountd,1000,2000 -j DROP parsing: 'mountd' -> 100005 parsing: '' -> 0 parsing: '' -> 0 iptables: No chain/target/match by that name Expected results without bogous patch: $ iptables -A INPUT -m rpc --rpcs mountd,1000,2000 -j DROP parsing: 'mountd' -> 100005 parsing: '1000' -> 1000 parsing: '2000' -> 2000 iptables: No chain/target/match by that name Additional info: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131848 https://lists.netfilter.org/pipermail/netfilter-devel/2004-September/016731.html
Created attachment 120764 [details] debug patch. do *not* apply to distribution.
Created attachment 120845 [details] Code cleanup patch I think this patch is a better solution for this problem. It is not good to point variables beyond the limits of buffers at all.
The "invalid" pointer is never used, the next operation will increment it to a vaild address. It's maybe not well/beauty written code, but there is no bug/problem at all. So, why not go with the upstream version?
Fixed in rawhide in rpm iptables-1.3.4-1 or newer.