From: Dries De Winter <dries.dewinter@gmail.com>
To: "David S. Miller" <davem@davemloft.net>,
Pablo Neira Ayuso <pablo@netfilter.org>,
Patrick McHardy <kaber@trash.net>
Cc: netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: [PATCH] net: ICMPv6 packets transmitted on wrong interface if nfmark is mangled
Date: Wed, 28 Nov 2012 10:09:55 +0100 (CET) [thread overview]
Message-ID: <14515182.2480.1354093791878.JavaMail.driesdw@sahwcmp0020> (raw)
In-Reply-To: <22884633.2468.1354092935228.JavaMail.driesdw@sahwcmp0020>
From: Dries De Winter <dries.dewinter@gmail.com>
The IPv6 mangle table may change the source/destination address and skb->mark
of a packet. Therefore it may be necessary to "reroute" a packet after it
traversed this table. But this should not happen for some special packets like
neighbour solicitations and MLD reports: they have an explicit destination, not
originating from the routing table. Rerouting these packets may cause them to
go out on the wrong interface or not to go out at all depending on the routing
table.
I propose a patch which allows to mark a dst_entry as "non-reroutable".
icmp6_dst_alloc() (used by ndisc and MLD implementation) will always mark the
allocated dst_entry as such. A check is added to netfilter (IPv6-only) so
packets heading for a non-reroutable destination are never rerouted.
Detailed discussion about the patch:
- It is based on 3.6.7.
- Are there other examples of dsts but ICMPv6 that should be non-reroutable?
- Are there other situations but rerouting by netfilter in which this new flag
should be considered?
- Similar logic exists in IPv4 so local multicast/broadcast messages are
potentially transmitted on the wrong interface. However, it's a less likely
corner case there because those packets are treated differently by
local output routing: multicast/broadcast messages are by default routed to
the interface with a matching source IP-address. But this logic is invalid
because (1) it is allowed to send messages with a source IP-address
different from your own and (2) it is allowed to assign the same IP-address
on multiple interfaces. So I feel that also in the case of IPv4 it should
be possible to forbid rerouting for some special packets.
Regards,
Dries De Winter
SoftAtHome
Signed-off-by: Dries De Winter <dries.dewinter@gmail.com>
---
diff --git a/include/net/dst.h b/include/net/dst.h
index 621e351..8b92678 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -61,6 +61,7 @@ struct dst_entry {
#define DST_NOPEER 0x0040
#define DST_FAKE_RTABLE 0x0080
#define DST_XFRM_TUNNEL 0x0100
+#define DST_NOREROUTE 0x0200
unsigned short pending_confirm;
diff --git a/net/ipv6/netfilter.c b/net/ipv6/netfilter.c
index db31561..5b98145 100644
--- a/net/ipv6/netfilter.c
+++ b/net/ipv6/netfilter.c
@@ -23,6 +23,10 @@ int ip6_route_me_harder(struct sk_buff *skb)
.saddr = iph->saddr,
};
+ dst = skb_dst(skb);
+ if (dst && (dst->flags & DST_NOREROUTE))
+ return 0;
+
dst = ip6_route_output(net, skb->sk, &fl6);
if (dst->error) {
IP6_INC_STATS(net, ip6_dst_idev(dst), IPSTATS_MIB_OUTNOROUTES);
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 070a3ce..1c7d377 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1234,7 +1234,7 @@ struct dst_entry *icmp6_dst_alloc(struct net_device *dev,
}
}
- rt->dst.flags |= DST_HOST;
+ rt->dst.flags |= DST_HOST | DST_NOREROUTE;
rt->dst.output = ip6_output;
rt->n = neigh;
atomic_set(&rt->dst.__refcnt, 1);
next parent reply other threads:[~2012-11-28 9:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <22884633.2468.1354092935228.JavaMail.driesdw@sahwcmp0020>
2012-11-28 9:09 ` Dries De Winter [this message]
2012-11-28 23:30 ` [PATCH] net: ICMPv6 packets transmitted on wrong interface if nfmark is mangled David Miller
2012-11-30 12:29 ` Dries De Winter
2012-11-30 17:22 ` David Miller
2012-12-03 12:46 ` Dries De Winter
2012-12-03 19:11 ` David Miller
2012-12-03 21:31 ` Dries De Winter
2012-12-03 22:06 ` David Miller
2012-12-05 13:41 ` Dries De Winter
2012-12-05 17:57 ` David Miller
2012-12-06 9:11 ` Dries De Winter
2012-12-03 23:38 ` Jan Engelhardt
2012-12-03 23:52 ` Pablo Neira Ayuso
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=14515182.2480.1354093791878.JavaMail.driesdw@sahwcmp0020 \
--to=dries.dewinter@gmail.com \
--cc=davem@davemloft.net \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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).