netdev - Suspicious fackets

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Apr 2007 14:28:21 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Netdev <netdev@...r.kernel.org>
cc:	David Miller <davem@...emloft.net>
Subject: Suspicious fackets_out handling

Hi,

While looking through the users of fackets_out, i found this from 
tcp_fragment(...):

	/* If this packet has been sent out already, we must
         * adjust the various packet counters.
         */
        if (!before(tp->snd_nxt, TCP_SKB_CB(buff)->end_seq)) {
		int diff = old_factor - tcp_skb_pcount(skb) -
                        tcp_skb_pcount(buff);

		[...snip...]

		if (diff > 0) {
                        /* Adjust Reno SACK estimate. */
                        if (!tp->rx_opt.sack_ok) {
                                tp->sacked_out -= diff;
                                if ((int)tp->sacked_out < 0)
                                        tp->sacked_out = 0;
                                tcp_sync_left_out(tp);
                        }

                        tp->fackets_out -= diff;
                        if ((int)tp->fackets_out < 0)
                                tp->fackets_out = 0;
                }
	}
	[...]

There are IMHO two problems in it. First of all, nothing ensures that the 
skb TCP is fragmenting is actually below the forwardmost sack block (and 
thus is included to the fackets_out)... What I'm not sure of though, is 
how to fix this in net-2.6(.22), it is due to the fact that there is no 
pointer/seq which can be used in testing for it like in tcp-2.6 which has 
the highest_sack. Second problem is even more obvious: if adjustment here 
is being done and the sacktag code then uses fastpath at the arrival of 
the next ACK, the sacktag code will use a stale value from 
fastpath_cnt_hint and fails to notice all that math TCP did here unless we 
start clearing fastpath_skb_hint.

-- 
 i.
-
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