netdev - Re: xfrm warning by mip6d

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1317810803.2473.37.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date:	Wed, 05 Oct 2011 12:33:23 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	András Takács <linux-kernel@...oond.hu>
Cc:	netdev@...r.kernel.org
Subject: Re: xfrm warning by mip6d

Le mercredi 05 octobre 2011 à 11:22 +0200, András Takács a écrit :
> Dear All,
> 
> We're running mip6d mobile IPv6 daemon on 2.6.35.13 kernel. While it is sending periodic Binding Update messages via raw IPv6 socket the following warning message appears:
> 
> [  946.883714] ------------[ cut here ]------------
> [  946.883714] WARNING: at trunk/kernel/linux-2.6.35.13/include/linux/skbuff.h:447 skb_dst.clone.22+0x42/0x44()
> [  946.883714] Hardware name: Bochs
> [  946.890048] Modules linked in: xfrm_user
> [  946.890179] Pid: 523, comm: mip6d Tainted: G        W   2.6.35.13-itssv6 #1
> [  946.890270] Call Trace:
> [  946.890354]  [<c0130e75>] warn_slowpath_common+0x65/0x7a
> [  946.890453]  [<c03e2b11>] ? skb_dst.clone.22+0x42/0x44
> [  946.890553]  [<c0130e99>] warn_slowpath_null+0xf/0x13
> [  946.890651]  [<c03e2b11>] skb_dst.clone.22+0x42/0x44
> [  946.890748]  [<c03e2e04>] ip6_finish_output2+0x15/0x23c
> [  946.890847]  [<c0130e99>] ? warn_slowpath_null+0xf/0x13
> [  946.890947]  [<c03e438f>] ip6_finish_output+0x8b3/0x8bf
> [  946.891048]  [<c0130c9c>] ? print_oops_end_marker+0x1e/0x23
> [  946.891151]  [<c0130e82>] ? warn_slowpath_common+0x72/0x7a
> [  946.891248]  [<c03e2b11>] ? skb_dst.clone.22+0x42/0x44
> [  946.891346]  [<c0130e99>] ? warn_slowpath_null+0xf/0x13
> [  946.891445]  [<c03e4443>] ip6_output+0xa8/0xb0
> [  946.891539]  [<c03dd551>] xfrm_output_resume+0x99/0x349
> [  946.891639]  [<c03dd80e>] xfrm_output2+0xd/0xf
> [  946.891732]  [<c03dd8a6>] xfrm_output+0x96/0xa0
> [  946.891828]  [<c0404fbf>] xfrm6_output_finish+0x13/0x15
> [  946.891928]  [<c04050fc>] xfrm6_output+0x4a/0x52
> [  946.892020]  [<c03e2b28>] dst_output+0x15/0x18
> [  946.892111]  [<c03e33b0>] ip6_local_out+0x17/0x1a
> [  946.892206]  [<c03e502c>] ip6_push_pending_frames+0x27c/0x31f
> [  946.892314]  [<c03f62f7>] rawv6_sendmsg+0xa79/0xb0b
> [  946.892411]  [<c014e7ad>] ? __lock_acquire+0x54f/0xbdc
> [  946.892525]  [<c03c932d>] inet_sendmsg+0x3d/0x46
> [  946.892623]  [<c0383b2f>] __sock_sendmsg+0x45/0x4e
> [  946.892722]  [<c0383f8f>] sock_sendmsg+0x92/0xa6
> [  946.892822]  [<c014eec2>] ? lock_release_non_nested+0x88/0x1f7
> [  946.892927]  [<c0177f81>] ? might_fault+0x46/0x80
> [  946.893023]  [<c0177f81>] ? might_fault+0x46/0x80
> [  946.893121]  [<c024a690>] ? _copy_from_user+0x39/0x4d
> [  946.893221]  [<c0385656>] sys_sendmsg+0x17d/0x1e1
> [  946.893331]  [<c014eec2>] ? lock_release_non_nested+0x88/0x1f7
> [  946.893436]  [<c0177f81>] ? might_fault+0x46/0x80
> [  946.893531]  [<c0177f81>] ? might_fault+0x46/0x80
> [  946.893628]  [<c0385a28>] sys_socketcall+0x14b/0x189
> [  946.893725]  [<c024a130>] ? trace_hardirqs_on_thunk+0xc/0x10
> [  946.893827]  [<c0119b17>] sysenter_do_call+0x12/0x36
> [  946.893915] ---[ end trace a2273a766b3b014c ]---
> 
> I tried to find the issue, and printed out the three condition values of WARN_ON macro:
> 
> [   61.686487] debug skb->_skb_refdst: 00000000CED5EA01 SKB_DST_NOREF 0000000000000001 ==> 0000000000000001
> [   61.686649] rcu_read_lock_held() 0
> [   61.686730] rcu_read_lock_bh_held() 0
> 
> I think, that the issue is somewhere in the xfrm module, which includes the Home Address Destination Option header, before ip6_output.
> 
> 
> Did anyone have the same issue before? Where do you thing the missing rcu lock is?
> 

Issue solved by commit 3bc07321ccc236f693ce1b6a8786f0a2e38bb87e

Thanks


commit 3bc07321ccc236f693ce1b6a8786f0a2e38bb87e
Author: Steffen Klassert <steffen.klassert@...unet.com>
Date:   Tue Mar 15 21:08:28 2011 +0000

    xfrm: Force a dst refcount before entering the xfrm type handlers
    
    Crypto requests might return asynchronous. In this case we leave
    the rcu protected region, so force a refcount on the skb's
    destination entry before we enter the xfrm type input/output
    handlers.
    
    This fixes a crash when a route is deleted whilst sending IPsec
    data that is transformed by an asynchronous algorithm.
    
    Signed-off-by: Steffen Klassert <steffen.klassert@...unet.com>
    Signed-off-by: David S. Miller <davem@...emloft.net>

diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 872065c..341cd11 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -190,6 +190,8 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
 		XFRM_SKB_CB(skb)->seq.input.low = seq;
 		XFRM_SKB_CB(skb)->seq.input.hi = seq_hi;
 
+		skb_dst_force(skb);
+
 		nexthdr = x->type->input(x, skb);
 
 		if (nexthdr == -EINPROGRESS)
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index 1aba03f..8f3f0ee 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -78,6 +78,8 @@ static int xfrm_output_one(struct sk_buff *skb, int err)
 
 		spin_unlock_bh(&x->lock);
 
+		skb_dst_force(skb);
+
 		err = x->type->output(x, skb);
 		if (err == -EINPROGRESS)
 			goto out_exit;



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