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]
Date:	Fri, 30 Mar 2007 14:43:47 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	ilpo.jarvinen@...sinki.fi
Cc:	akpm@...ux-foundation.org, netdev@...r.kernel.org
Subject: Re: tcp crash in net-2.6 tree

From: "Ilpo_Järvinen" <ilpo.jarvinen@...sinki.fi>
Date: Fri, 30 Mar 2007 17:33:28 +0300 (EEST)

> If there is nothing at high_seq (application hasn't given any data to/past 
> that point), the search fails to find any skb and returns NULL... But I 
> have no idea how this can happen? As TCP does after(skb->seq, 
> tp->high_seq) (even in the quoted code block) guaranteeing that something 
> is there after the high_seq for TCP to step temporarily on... So at least 
> one skb should have it's end_seq after tp->high_seq (actually there 
> should be at least two valid skbs after tp->high_seq since the used 
> sequence number space does not have holes), which should be enough to get 
> an existing skb from write_queue_find?!
> 
> I also checked all call paths to tcp_update_scoreboard_fack to make sure 
> that snd_una hasn't gone past high_seq and found nothing suspicious (and 
> that wouldn't return NULL anyway I think)...

Let's not speculate, let's find out for sure if snd_una is
surpassing high_seq while we're in this state.

Andrew please give this debugging patch a spin, and also what
is your workload?  I'd like to play with it too.

I've tried to code this patch so that if the bug triggers your
machine shouldn't crash and burn completely, just spit out the
log message.

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 97b9be2..605b5a8 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1936,14 +1936,32 @@ static void tcp_update_scoreboard_fack(struct sock *sk, u32 entry_seq,
 
 		if ((!IsFack(tp) || !tcp_skb_timedout(sk, skb)) &&
 		    after(TCP_SKB_CB(skb)->seq, tp->high_seq)) {
+			if (after(tp->snd_una, tp->high_seq)) {
+				printk(KERN_ALERT "TCP BUG: snd_una>high_seq "
+				       "[%08x:%08x]\n",
+				       tp->snd_una, tp->high_seq);
+				goto skip;
+			}
 			/* RFC: should we have find_below? */
 			skb = tcp_write_queue_find(sk, tp->high_seq);
+			if (!skb) {
+				struct sk_buff *head = tcp_write_queue_head(sk);
+				struct sk_buff *tail = tcp_write_queue_tail(sk);
+				printk(KERN_ALERT "TCP BUG: high_seq==NULL "
+				       "[%08x] q[%08x] t[%08x]\n",
+				       tp->high_seq,
+				       TCP_SKB_CB(head)->seq,
+				       TCP_SKB_CB(tail)->end_seq);
+				goto skip;
+				       
+			}
 			not_marked_skb = skb;
 			skb = tcp_write_queue_prev(sk, skb);
 			/* Timedout top is again uncertain? */
 			if (tcp_skb_timedout(sk, skb))
 				timedout_continue = 1;
 		}
+skip:
 		/* RFC: ...else if (!tcp_skb_timedout) do skb fragmentation? */
 
 		/* Phase II: Marker */
-
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

Powered by blists - more mailing lists