| 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
| ||
|
Message-ID: <20070125191957.GD22455@galon.ev-en.org> Date: Thu, 25 Jan 2007 21:19:57 +0200 From: Baruch Even <baruch@...en.org> To: netdev@...r.kernel.org Cc: Stephen Hemminger <shemminger@...l.org>, Douglas Leith <doug@....strath.ac.uk> Subject: Possible bugs in SACK processing In addition to the patch I've provided there are two more issues that I believe are bugs in the SACK processing code. Since I'm not certain but I don't have the time to look into them I'd like to raise them for other folks to look at. First issue is the checking of the applicability of the fast path. The sack blocks are compared directly, but there is no comparison of the number of sack blocks. If in the former sack we had two blocks and now we have three we will compare the third sack block from now against old or uninitialised data. The chance of anything really bad happening might not be high but it seems to be a bad behaviour. The second issue is that there is no check that the fast path is actually behind the hint. Consider a scenario where we have three sack blocks and the first sack update is about an old location. And then comes another sack packet with only an update to the old location. The result will be that after the former sack block the hint is in the latest location it can be and when the next sack packet arrives we detect its an increase only but the fast path hint is too far and we do no updating at all. Baruch - 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