> <i>The commit was made in May 2014. It was applied to the Ubuntu trusty kernel tree in June 2014. There was no mention of the security implications of the bug in the commit message, or elsewhere, so far as we can tell.</i><p>Linus did mention his policy on this [1].<p><pre><code> On Tue, 15 Jul 2008, pageexec <at> freemail.hu wrote:
>
> by 'cover up' i meant that even when you know better, you quite
> consciously do *not* report the security impact of said bugs
Yes. Because the only place I consider appropriate is the kernel
changelogs, and since those get published with the sources, there is no
way I can convince myself that it's a good idea to say "Hey script
kiddies, try this" unless it's already very public indeed.
</code></pre>
He also talked about this recently at debconf14 [2].<p>[1] <a href="http://thread.gmane.org/gmane.linux.kernel/701694/focus=706947" rel="nofollow">http://thread.gmane.org/gmane.linux.kernel/701694/focus=7069...</a><p>[2] <a href="http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/QA_with_Linus_Torvalds.webm" rel="nofollow">http://meetings-archive.debian.net/pub/debian-meetings/2014/...</a>
Look at that code change. An incredibly obscure feature of GCC was used to save two machine instruction times in security-critical code. That was either stupid or a deliberate insertion of a security hole.
If your system security depends in any way on a randomly initialized TCP sequence number, you're asking for trouble.<p>It seems it would be preferable to use predictable values so people don't get the impression that random values are somehow more secure.