Andrew Morton wrote:
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
Latest working kernel version: up to at least 2.6.24
Earliest failing kernel version: first noticed with upgrade to 2.6.28
So it's a regression?
Yes. The fix is on its way upstream.
Possible solutions:
- initialize the addr variable in recent_mt_proc_write
- compare only 4 bytes for IPv4 addresses in recent_entry_lookup
Simplest fix:
--- linux-2.6.28.7/net/netfilter/xt_recent.c.org 2009-02-22
17:34:19.000000000 +0100
+++ linux-2.6.28.7/net/netfilter/xt_recent.c 2009-02-22 17:34:21.000000000
+0100
@@ -544,7 +544,7 @@
struct recent_entry *e;
char buf[sizeof("+b335:1d35:1e55:dead:c0de:1715:5afe:c0de")];
const char *c = buf;
- union nf_inet_addr addr;
+ union nf_inet_addr addr = {};
u_int16_t family;
bool add, succ;
hm, that function does some pretty ugly things.
I wonder if the same bug exists elsewhere (or might do so in the
future). A more general fix would be to write a new
in6_to_nf_inet_addr() and in4_to_nf_inet_addr() which correctly
initialise the whole union.
I don't think thats necessary, there are no intentions of adding
more text-based interfaces.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
