<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>dexen</author><text>&lt;i&gt;&amp;gt;The failures of the Linux core team to properly prioritize security&lt;/i&gt;&lt;p&gt;Why even post this, when it has nothing to do the with the case GP &amp;amp; OP described? It&amp;#x27;s misleading at best.&lt;p&gt;The failure here is in the way Google has set its Android development process. They keep a separate &amp;quot;stable&amp;quot; kernel, and manually select certain patches to backport to. In process they skip all kinds of patches - performance, features, and yes, security ones. Given that only selected patches are backported, the process is best described as &lt;i&gt;insecure by default&lt;/i&gt;. It was Google&amp;#x27;s decision to favor stable API over security here.&lt;p&gt;This is compounded by the fact other Android phone vendors are pretty slow at releasing OS upgrade - and tend to stop releasing them altogether shortly after the phone&amp;#x27;s no longer manufactured.&lt;p&gt;The mainline kernel, as released by the &lt;i&gt;Linux core team&lt;/i&gt; is up to date with security. Hold to account people that decided to skip patches as a matter of course, resulting in the &lt;i&gt;insecure by default&lt;/i&gt; process.</text><parent_chain><item><author>dmix</author><text>The failures of the Linux core team to properly prioritize security is quite well known. A lot of people have poked the bear by trying to bring this up, also with specific real examples, and got a tongue lashing from the team and moved on to other things.&lt;p&gt;I&amp;#x27;m amazed the GRSecurity people have managed to do it for so long. Even if merging their stuff mainline legitimately wasn&amp;#x27;t practical, I&amp;#x27;ve seen plenty of snark and dismissiveness from the Linux team towards them and others. And GRSEC does actively bring in CVEs into their kernel patches all the time and get paid via sponsors to do so.&lt;p&gt;I&amp;#x27;m sure going through old CVEs is a great way to find &amp;quot;zero days&amp;quot; and&amp;#x2F;or relapses after old patches. Or even just following the work GRSec does there&amp;#x27;s probably plenty of stuff for a highly motivated company like NSO to exploit.</text></item><item><author>typical182</author><text>To me, the biggest part of this story is:&lt;p&gt;1. Over two years ago, this was apparently detected automatically by the syzkaller kernel fuzzer, and automatically reported on its public mailing list. [1]&lt;p&gt;2. Over a year and a half ago, it was apparently fixed in the upstream kernel. [2]&lt;p&gt;3. It was apparently never merged back to various &amp;quot;stable&amp;quot; kernels, leading to the recent CVE. [3]&lt;p&gt;So you might read that and think &amp;quot;Ok, probably a rare mistake&amp;quot;...&lt;p&gt;...but instead:&lt;p&gt;4. This is apparently a _super_ common sequence of events, with kernel vulnerabilities getting lost in the shuffle, or otherwise not backported to &amp;quot;stable&amp;quot; kernels for a variety of reasons like the patch no cleanly longer applies.&lt;p&gt;Dmitry Vyukov (original author of syzkaller fuzzer that found this 2 years ago) gave a very interesting talk on how frequently  this happens a couple weeks ago at the Linux Maintainer&amp;#x27;s Summit, along with some discussion of how to change kernel dev processes to try to dramatically improve things:&lt;p&gt;slides: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;linuxplumbersconf.org&amp;#x2F;event&amp;#x2F;4&amp;#x2F;contributions&amp;#x2F;554&amp;#x2F;attachments&amp;#x2F;353&amp;#x2F;584&amp;#x2F;Reflections__Kernel_Summit_2019.pdf&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;linuxplumbersconf.org&amp;#x2F;event&amp;#x2F;4&amp;#x2F;contributions&amp;#x2F;554&amp;#x2F;atta...&lt;/a&gt;&lt;p&gt;video: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;a2Nv-KJyqPk?t=5239&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;a2Nv-KJyqPk?t=5239&lt;/a&gt;&lt;p&gt;---&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;twitter.com&amp;#x2F;dvyukov&amp;#x2F;status&amp;#x2F;1180195777680986113&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;twitter.com&amp;#x2F;dvyukov&amp;#x2F;status&amp;#x2F;1180195777680986113&lt;/a&gt;&lt;p&gt;[2] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;git.kernel.org&amp;#x2F;pub&amp;#x2F;scm&amp;#x2F;linux&amp;#x2F;kernel&amp;#x2F;git&amp;#x2F;stable&amp;#x2F;linux.git&amp;#x2F;commit&amp;#x2F;drivers&amp;#x2F;android&amp;#x2F;binder.c?h=linux-4.14.y&amp;amp;id=7a3cee43e935b9d526ad07f20bf005ba7e74d05b&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;git.kernel.org&amp;#x2F;pub&amp;#x2F;scm&amp;#x2F;linux&amp;#x2F;kernel&amp;#x2F;git&amp;#x2F;stable&amp;#x2F;linux...&lt;/a&gt;&lt;p&gt;[3] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;mobile.twitter.com&amp;#x2F;grsecurity&amp;#x2F;status&amp;#x2F;1180059539233804288&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;mobile.twitter.com&amp;#x2F;grsecurity&amp;#x2F;status&amp;#x2F;118005953923380...&lt;/a&gt;</text></item></parent_chain></comment><story><title>Google, Xiaomi, and Huawei affected by zero-day flaw that unlocks root access</title><url>https://thenextweb.com/security/2019/10/04/google-xiaomi-and-huawei-devices-affected-by-zero-day-flaw-that-unlocks-root-access/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>lucb1e</author><text>&amp;gt; failures of the Linux core team&lt;p&gt;But isn&amp;#x27;t the issue that Android didn&amp;#x27;t merge it? Linux patched it.</text><parent_chain><item><author>dmix</author><text>The failures of the Linux core team to properly prioritize security is quite well known. A lot of people have poked the bear by trying to bring this up, also with specific real examples, and got a tongue lashing from the team and moved on to other things.&lt;p&gt;I&amp;#x27;m amazed the GRSecurity people have managed to do it for so long. Even if merging their stuff mainline legitimately wasn&amp;#x27;t practical, I&amp;#x27;ve seen plenty of snark and dismissiveness from the Linux team towards them and others. And GRSEC does actively bring in CVEs into their kernel patches all the time and get paid via sponsors to do so.&lt;p&gt;I&amp;#x27;m sure going through old CVEs is a great way to find &amp;quot;zero days&amp;quot; and&amp;#x2F;or relapses after old patches. Or even just following the work GRSec does there&amp;#x27;s probably plenty of stuff for a highly motivated company like NSO to exploit.</text></item><item><author>typical182</author><text>To me, the biggest part of this story is:&lt;p&gt;1. Over two years ago, this was apparently detected automatically by the syzkaller kernel fuzzer, and automatically reported on its public mailing list. [1]&lt;p&gt;2. Over a year and a half ago, it was apparently fixed in the upstream kernel. [2]&lt;p&gt;3. It was apparently never merged back to various &amp;quot;stable&amp;quot; kernels, leading to the recent CVE. [3]&lt;p&gt;So you might read that and think &amp;quot;Ok, probably a rare mistake&amp;quot;...&lt;p&gt;...but instead:&lt;p&gt;4. This is apparently a _super_ common sequence of events, with kernel vulnerabilities getting lost in the shuffle, or otherwise not backported to &amp;quot;stable&amp;quot; kernels for a variety of reasons like the patch no cleanly longer applies.&lt;p&gt;Dmitry Vyukov (original author of syzkaller fuzzer that found this 2 years ago) gave a very interesting talk on how frequently  this happens a couple weeks ago at the Linux Maintainer&amp;#x27;s Summit, along with some discussion of how to change kernel dev processes to try to dramatically improve things:&lt;p&gt;slides: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;linuxplumbersconf.org&amp;#x2F;event&amp;#x2F;4&amp;#x2F;contributions&amp;#x2F;554&amp;#x2F;attachments&amp;#x2F;353&amp;#x2F;584&amp;#x2F;Reflections__Kernel_Summit_2019.pdf&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;linuxplumbersconf.org&amp;#x2F;event&amp;#x2F;4&amp;#x2F;contributions&amp;#x2F;554&amp;#x2F;atta...&lt;/a&gt;&lt;p&gt;video: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;a2Nv-KJyqPk?t=5239&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;a2Nv-KJyqPk?t=5239&lt;/a&gt;&lt;p&gt;---&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;twitter.com&amp;#x2F;dvyukov&amp;#x2F;status&amp;#x2F;1180195777680986113&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;twitter.com&amp;#x2F;dvyukov&amp;#x2F;status&amp;#x2F;1180195777680986113&lt;/a&gt;&lt;p&gt;[2] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;git.kernel.org&amp;#x2F;pub&amp;#x2F;scm&amp;#x2F;linux&amp;#x2F;kernel&amp;#x2F;git&amp;#x2F;stable&amp;#x2F;linux.git&amp;#x2F;commit&amp;#x2F;drivers&amp;#x2F;android&amp;#x2F;binder.c?h=linux-4.14.y&amp;amp;id=7a3cee43e935b9d526ad07f20bf005ba7e74d05b&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;git.kernel.org&amp;#x2F;pub&amp;#x2F;scm&amp;#x2F;linux&amp;#x2F;kernel&amp;#x2F;git&amp;#x2F;stable&amp;#x2F;linux...&lt;/a&gt;&lt;p&gt;[3] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;mobile.twitter.com&amp;#x2F;grsecurity&amp;#x2F;status&amp;#x2F;1180059539233804288&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;mobile.twitter.com&amp;#x2F;grsecurity&amp;#x2F;status&amp;#x2F;118005953923380...&lt;/a&gt;</text></item></parent_chain></comment><story><title>Google, Xiaomi, and Huawei affected by zero-day flaw that unlocks root access</title><url>https://thenextweb.com/security/2019/10/04/google-xiaomi-and-huawei-devices-affected-by-zero-day-flaw-that-unlocks-root-access/</url></story>