Patchwork (ipt_log_packet, sb_add) 3.6.0-rc2 kernel panic - not syncing; Fatal exception in interrupt

login
register
mail settings
Submitter Eric Dumazet
Date Sept. 2, 2012, 10:53 p.m.
Message ID <1346626385.2563.44.camel@edumazet-glaptop>
Download mbox | patch
Permalink /patch/181270/
State Not Applicable
Delegated to: David Miller
Headers show

Comments

Eric Dumazet - Sept. 2, 2012, 10:53 p.m.
From: Eric Dumazet <edumazet@google.com>

On Sun, 2012-09-02 at 15:28 +0200, Florian Westphal wrote:
> Sami Farin <hvtaifwkbgefbaei@gmail.com> wrote:
> > I get this panic every 1-2 days.
> > Also with 7a611e69b26069a511d9d5251c6a28af6c521121 (commit before 3.6.0-rc4).
> 
> Could you please post iptables-save output?
> My guess is you're using NFLOG in INPUT?
> 
> If so, I bet its caused by the tcp early demux stuff.
> Does that crash go away with ip_early_demux sysctl off?
> 
> My guess is its assigning skb->sk with TIMEWAIT sockets, which
> would explain the crash.

Yes thats probably the reason.

First I thought changing demux to not do the lookup of TIMEWAIT slot in
__inet_lookup_established(), then it sounds not optimal to redo the full
lookup for ESTABLISHED sockets later in TCP stack.

So it seems we should fix xt_LOG instead

Thanks Florian !

[PATCH] xt_LOG: take care of timewait sockets

Sami Farin reported crashes in xt_LOG because it assumes skb->sk is a
full blown socket.

But with TCP early demux, we can have skb->sk pointing to a timewait
socket.

Diagnosed-by: Florian Westphal <fw@strlen.de>
Reported-by: Sami Farin <hvtaifwkbgefbaei@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 net/netfilter/xt_LOG.c |   33 +++++++++++++++++----------------
 1 file changed, 17 insertions(+), 16 deletions(-)



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Eric Dumazet - Sept. 2, 2012, 11:37 p.m.
On Mon, 2012-09-03 at 00:53 +0200, Eric Dumazet wrote:

> First I thought changing demux to not do the lookup of TIMEWAIT slot in
> __inet_lookup_established(), then it sounds not optimal to redo the full
> lookup for ESTABLISHED sockets later in TCP stack.
> 
> So it seems we should fix xt_LOG instead
> 
> Thanks Florian !
> 
> [PATCH] xt_LOG: take care of timewait sockets
> 
> Sami Farin reported crashes in xt_LOG because it assumes skb->sk is a
> full blown socket.
> 
> But with TCP early demux, we can have skb->sk pointing to a timewait
> socket.

Seems other fixes are needed, for example in nfnetlink_log.c

I'll send a v2


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Engelhardt - Sept. 10, 2012, 5:02 a.m.
On Monday 2012-09-03 00:53, Eric Dumazet wrote:
>[PATCH] xt_LOG: take care of timewait sockets
>
>Sami Farin reported crashes in xt_LOG because it assumes skb->sk is a
>full blown socket.
>
>But with TCP early demux, we can have skb->sk pointing to a timewait
>socket.
>
>+static void dump_sk_uid_gid(struct sbuff *m, struct sock *sk)
>+{
>+	if (!sk || sk->sk_state == TCP_TIME_WAIT)
>+		return;
>+
>+	read_lock_bh(&sk->sk_callback_lock);
>+	if (sk->sk_socket && sk->sk_socket->file)
>+		sb_add(m, "UID=%u GID=%u ",
>+			sk->sk_socket->file->f_cred->fsuid,
>+			sk->sk_socket->file->f_cred->fsgid);

xt_owner.c is also using f_cred, so it might need the same,
does it not?

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Eric Dumazet - Sept. 10, 2012, 6 a.m.
On Mon, 2012-09-10 at 07:02 +0200, Jan Engelhardt wrote:
> On Monday 2012-09-03 00:53, Eric Dumazet wrote:
> >[PATCH] xt_LOG: take care of timewait sockets
> >
> >Sami Farin reported crashes in xt_LOG because it assumes skb->sk is a
> >full blown socket.
> >
> >But with TCP early demux, we can have skb->sk pointing to a timewait
> >socket.
> >
> >+static void dump_sk_uid_gid(struct sbuff *m, struct sock *sk)
> >+{
> >+	if (!sk || sk->sk_state == TCP_TIME_WAIT)
> >+		return;
> >+
> >+	read_lock_bh(&sk->sk_callback_lock);
> >+	if (sk->sk_socket && sk->sk_socket->file)
> >+		sb_add(m, "UID=%u GID=%u ",
> >+			sk->sk_socket->file->f_cred->fsuid,
> >+			sk->sk_socket->file->f_cred->fsgid);
> 
> xt_owner.c is also using f_cred, so it might need the same,
> does it not?

Right.

AFAIK, xt_owner would make little sense in input path, no ?

static struct xt_match owner_mt_reg __read_mostly = {
        .name       = "owner",
        .revision   = 1,
        .family     = NFPROTO_UNSPEC,
        .checkentry = owner_check,
        .match      = owner_mt,
        .matchsize  = sizeof(struct xt_owner_match_info),
        .hooks      = (1 << NF_INET_LOCAL_OUT) |
                      (1 << NF_INET_POST_ROUTING),
        .me         = THIS_MODULE,
};


So it seems we have nothing to do at this moment.




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/net/netfilter/xt_LOG.c b/net/netfilter/xt_LOG.c
index ff5f75f..2a4f969 100644
--- a/net/netfilter/xt_LOG.c
+++ b/net/netfilter/xt_LOG.c
@@ -145,6 +145,19 @@  static int dump_tcp_header(struct sbuff *m, const struct sk_buff *skb,
 	return 0;
 }
 
+static void dump_sk_uid_gid(struct sbuff *m, struct sock *sk)
+{
+	if (!sk || sk->sk_state == TCP_TIME_WAIT)
+		return;
+
+	read_lock_bh(&sk->sk_callback_lock);
+	if (sk->sk_socket && sk->sk_socket->file)
+		sb_add(m, "UID=%u GID=%u ",
+			sk->sk_socket->file->f_cred->fsuid,
+			sk->sk_socket->file->f_cred->fsgid);
+	read_unlock_bh(&sk->sk_callback_lock);
+}
+
 /* One level of recursion won't kill us */
 static void dump_ipv4_packet(struct sbuff *m,
 			const struct nf_loginfo *info,
@@ -361,14 +374,8 @@  static void dump_ipv4_packet(struct sbuff *m,
 	}
 
 	/* Max length: 15 "UID=4294967295 " */
-	if ((logflags & XT_LOG_UID) && !iphoff && skb->sk) {
-		read_lock_bh(&skb->sk->sk_callback_lock);
-		if (skb->sk->sk_socket && skb->sk->sk_socket->file)
-			sb_add(m, "UID=%u GID=%u ",
-				skb->sk->sk_socket->file->f_cred->fsuid,
-				skb->sk->sk_socket->file->f_cred->fsgid);
-		read_unlock_bh(&skb->sk->sk_callback_lock);
-	}
+	if ((logflags & XT_LOG_UID) && !iphoff)
+		dump_sk_uid_gid(m, skb->sk);
 
 	/* Max length: 16 "MARK=0xFFFFFFFF " */
 	if (!iphoff && skb->mark)
@@ -717,14 +724,8 @@  static void dump_ipv6_packet(struct sbuff *m,
 	}
 
 	/* Max length: 15 "UID=4294967295 " */
-	if ((logflags & XT_LOG_UID) && recurse && skb->sk) {
-		read_lock_bh(&skb->sk->sk_callback_lock);
-		if (skb->sk->sk_socket && skb->sk->sk_socket->file)
-			sb_add(m, "UID=%u GID=%u ",
-				skb->sk->sk_socket->file->f_cred->fsuid,
-				skb->sk->sk_socket->file->f_cred->fsgid);
-		read_unlock_bh(&skb->sk->sk_callback_lock);
-	}
+	if ((logflags & XT_LOG_UID) && recurse)
+		dump_sk_uid_gid(m, skb->sk);
 
 	/* Max length: 16 "MARK=0xFFFFFFFF " */
 	if (!recurse && skb->mark)