This is a note to let you know that I've just added the patch titled
ip_forward: Drop frames with attached skb->sk
to the 3.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ip_forward-drop-frames-with-attached-skb-sk.patch
and it can be found in the queue-3.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From foo@baz Wed Apr 29 12:00:42 CEST 2015
From: =?UTF-8?q?Sebastian=20P=C3=B6hn?= <sebastian.poehn@xxxxxxxxx>
Date: Mon, 20 Apr 2015 09:19:20 +0200
Subject: ip_forward: Drop frames with attached skb->sk
From: =?UTF-8?q?Sebastian=20P=C3=B6hn?= <sebastian.poehn@xxxxxxxxx>
[ Upstream commit 2ab957492d13bb819400ac29ae55911d50a82a13 ]
Initial discussion was:
[FYI] xfrm: Don't lookup sk_policy for timewait sockets
Forwarded frames should not have a socket attached. Especially
tw sockets will lead to panics later-on in the stack.
This was observed with TPROXY assigning a tw socket and broken
policy routing (misconfigured). As a result frame enters
forwarding path instead of input. We cannot solve this in
TPROXY as it cannot know that policy routing is broken.
v2:
Remove useless comment
Signed-off-by: Sebastian Poehn <sebastian.poehn@xxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
net/ipv4/ip_forward.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/ipv4/ip_forward.c
+++ b/net/ipv4/ip_forward.c
@@ -126,6 +126,9 @@ int ip_forward(struct sk_buff *skb)
struct rtable *rt; /* Route we use */
struct ip_options *opt = &(IPCB(skb)->opt);
+ if (unlikely(skb->sk))
+ goto drop;
+
if (skb_warn_if_lro(skb))
goto drop;
Patches currently in stable-queue which might be from sebastian.poehn@xxxxxxxxx are
queue-3.10/ip_forward-drop-frames-with-attached-skb-sk.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html