netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, Patrick McHardy <kaber@trash.net>,
	netfilter-devel@vger.kernel.org
Subject: netfilter 06/06: xt_recent: fix proc-file addition/removal of IPv4 addresses
Date: Tue, 24 Feb 2009 15:52:51 +0100 (MET)	[thread overview]
Message-ID: <20090224145251.9789.74927.sendpatchset@x2.localnet> (raw)
In-Reply-To: <20090224145243.9789.60678.sendpatchset@x2.localnet>

commit 325fb5b4d26038cba665dd0d8ee09555321061f0
Author: Josef Drexler <joe-lk@ttdpatch.net>
Date:   Tue Feb 24 14:53:12 2009 +0100

    netfilter: xt_recent: fix proc-file addition/removal of IPv4 addresses
    
    Fix regression introduded by commit 079aa88 (netfilter: xt_recent: IPv6 support):
    
    From http://bugzilla.kernel.org/show_bug.cgi?id=12753:
    
    Problem Description:
    An uninitialized buffer causes IPv4 addresses added manually (via the +IP
    command to the proc interface) to never match any packets. Similarly, the -IP
    command fails to remove IPv4 addresses.
    
    Details:
    In the function recent_entry_lookup, the xt_recent module does comparisons of
    the entire nf_inet_addr union value, both for IPv4 and IPv6 addresses. For
    addresses initialized from actual packets the remaining 12 bytes not occupied
    by the IPv4 are zeroed so this works correctly. However when setting the
    nf_inet_addr addr variable in the recent_mt_proc_write function, only the IPv4
    bytes are initialized and the remaining 12 bytes contain garbage.
    
    Hence addresses added in this way never match any packets, unless these
    uninitialized 12 bytes happened to be zero by coincidence. Similarly, addresses
    cannot consistently be removed using the proc interface due to mismatch of the
    garbage bytes (although it will sometimes work to remove an address that was
    added manually).
    
    Reading the /proc/net/xt_recent/ entries hides this problem because this only
    uses the first 4 bytes when displaying IPv4 addresses.
    
    Steps to reproduce:
    $ iptables -I INPUT -m recent --rcheck -j LOG
    $ echo +169.254.156.239 > /proc/net/xt_recent/DEFAULT
    $ cat /proc/net/xt_recent/DEFAULT
    src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
    
    [At this point no packets from 169.254.156.239 are being logged.]
    
    $ iptables -I INPUT -s 169.254.156.239 -m recent --set
    $ cat /proc/net/xt_recent/DEFAULT
    src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
    src=169.254.156.239 ttl: 255 last_seen: 126184 oldest_pkt: 4 125434, 125684, 125934, 126184
    
    [At this point, adding the address via an iptables rule, packets are being
    logged correctly.]
    
    $ echo -169.254.156.239 > /proc/net/xt_recent/DEFAULT
    $ cat /proc/net/xt_recent/DEFAULT
    src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
    src=169.254.156.239 ttl: 255 last_seen: 126992 oldest_pkt: 10 125434, 125684, 125934, 126184, 126434, 126684, 126934, 126991, 126991, 126992
    $ echo -169.254.156.239 > /proc/net/xt_recent/DEFAULT
    $ cat /proc/net/xt_recent/DEFAULT
    src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
    src=169.254.156.239 ttl: 255 last_seen: 126992 oldest_pkt: 10 125434, 125684, 125934, 126184, 126434, 126684, 126934, 126991, 126991, 126992
    
    [Removing the address via /proc interface failed evidently.]
    
    Possible solutions:
    - initialize the addr variable in recent_mt_proc_write
    - compare only 4 bytes for IPv4 addresses in recent_entry_lookup
    
    Signed-off-by: Patrick McHardy <kaber@trash.net>

diff --git a/net/netfilter/xt_recent.c b/net/netfilter/xt_recent.c
index fe80b61..791e030 100644
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -542,7 +542,7 @@ recent_mt_proc_write(struct file *file, const char __user *input,
 	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;
 

  parent reply	other threads:[~2009-02-24 14:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-24 14:52 netfilter 00/06: netfilter fixes Patrick McHardy
2009-02-24 14:52 ` netfilter 01/06: nf_conntrack_ipv6: fix nf_log_packet message in icmpv6 conntrack Patrick McHardy
2009-02-24 14:52 ` netfilter 02/06: nfnetlink_log: fix per-rule qthreshold override Patrick McHardy
2009-02-24 14:52 ` netfilter 03/06: nfnetlink_log: fix timeout handling Patrick McHardy
2009-02-24 14:52 ` netfilter 04/06: nf_conntrack: don't try to deliver events for untracked connections Patrick McHardy
2009-02-24 14:52 ` netfilter 05/06: make proc/net/ip* print names from foreign NFPROTO Patrick McHardy
2009-02-24 14:52 ` Patrick McHardy [this message]
2009-02-24 21:50 ` netfilter 00/06: netfilter fixes David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090224145251.9789.74927.sendpatchset@x2.localnet \
    --to=kaber@trash.net \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).