<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_07_18_0136224</id>
	<title>New Linux Kernel Flaw Allows Null Pointer Exploits</title>
	<author>Soulskill</author>
	<datestamp>1247919420000</datestamp>
	<htmltext>Trailrunner7 writes <i>"A <a href="http://threatpost.com/blogs/researcher-uses-new-linux-kernel-flaw-bypass-selinux-other-protections"> new flaw in the latest release of the Linux kernel</a> gives attackers the ability to exploit NULL pointer dereferences and bypass the protections of SELinux, AppArmor and the Linux Security Module. Brad Spengler discovered the vulnerability and found a reliable way to exploit it, giving him complete control of the remote machine. This is somewhat similar to the magic that Mark Dowd performed last year to <a href="//slashdot.org/article.pl?sid=08/04/18/0436232&amp;tid=952">exploit Adobe Flash</a>. Threatpost.com reports: 'The vulnerability is in the 2.6.30 release of the Linux kernel, and in a message to the Daily Dave mailing list Spengler said that he was able to exploit the flaw, which at first glance seemed unexploitable. He said that he was able to defeat the protection against exploiting NULL pointer dereferences on systems running SELinux and those running typical Linux implementations.'"</i></htmltext>
<tokenext>Trailrunner7 writes " A new flaw in the latest release of the Linux kernel gives attackers the ability to exploit NULL pointer dereferences and bypass the protections of SELinux , AppArmor and the Linux Security Module .
Brad Spengler discovered the vulnerability and found a reliable way to exploit it , giving him complete control of the remote machine .
This is somewhat similar to the magic that Mark Dowd performed last year to exploit Adobe Flash .
Threatpost.com reports : 'The vulnerability is in the 2.6.30 release of the Linux kernel , and in a message to the Daily Dave mailing list Spengler said that he was able to exploit the flaw , which at first glance seemed unexploitable .
He said that he was able to defeat the protection against exploiting NULL pointer dereferences on systems running SELinux and those running typical Linux implementations .
' "</tokentext>
<sentencetext>Trailrunner7 writes "A  new flaw in the latest release of the Linux kernel gives attackers the ability to exploit NULL pointer dereferences and bypass the protections of SELinux, AppArmor and the Linux Security Module.
Brad Spengler discovered the vulnerability and found a reliable way to exploit it, giving him complete control of the remote machine.
This is somewhat similar to the magic that Mark Dowd performed last year to exploit Adobe Flash.
Threatpost.com reports: 'The vulnerability is in the 2.6.30 release of the Linux kernel, and in a message to the Daily Dave mailing list Spengler said that he was able to exploit the flaw, which at first glance seemed unexploitable.
He said that he was able to defeat the protection against exploiting NULL pointer dereferences on systems running SELinux and those running typical Linux implementations.
'"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740451</id>
	<title>Re:Double standards</title>
	<author>Fweeky</author>
	<datestamp>1247929380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In my tests, gcc only optimizes out null checks at -O3 or above, which is already known to make potentially unsafe optimizations.  Maybe if -Wunreachable-code were part of -Wall it would have been easier to spot.</p></htmltext>
<tokenext>In my tests , gcc only optimizes out null checks at -O3 or above , which is already known to make potentially unsafe optimizations .
Maybe if -Wunreachable-code were part of -Wall it would have been easier to spot .</tokentext>
<sentencetext>In my tests, gcc only optimizes out null checks at -O3 or above, which is already known to make potentially unsafe optimizations.
Maybe if -Wunreachable-code were part of -Wall it would have been easier to spot.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739977</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739999</id>
	<title>Just like Linux</title>
	<author>Anonymous</author>
	<datestamp>1247924640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>More and More like windows everyday</p></htmltext>
<tokenext>More and More like windows everyday</tokentext>
<sentencetext>More and More like windows everyday</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28751327</id>
	<title>Re:Wait, what?</title>
	<author>ratboy666</author>
	<datestamp>1248008640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You are confusing the two things --</p><p>A "pointer" is not an "address". It is not legal to dereference a pointer containing 0. If "0" is a valid address, AND an object could be located there, it would still be necessary to refer to it by something other than "0".</p><p>Now, it so happens that addresses are typically used as pointers, and "0" is simply not allowed as an object address. Which<br>also works.</p><p>But, it is true that a dereference from 0 gives undefined behaviour,  so, to preserve semantics the compiler CAN make this assumption. This transformation is just as legal as:</p><p>if (!p) do1();<br>if (!p) do2();</p><p>if do1() has no way of reaching p, transform to:</p><p>if (!p) {do1(); do2();}</p><p>Of course, if p is global, or otherwise reachable from do1(), this transformation isn't legal. But, in this case, tun can be assumed non-NULL, and the optimization made, because the OTHER interpretation allows it as well (undefined, eg. better than turning your computer into a goat or something).</p></htmltext>
<tokenext>You are confusing the two things --A " pointer " is not an " address " .
It is not legal to dereference a pointer containing 0 .
If " 0 " is a valid address , AND an object could be located there , it would still be necessary to refer to it by something other than " 0 " .Now , it so happens that addresses are typically used as pointers , and " 0 " is simply not allowed as an object address .
Whichalso works.But , it is true that a dereference from 0 gives undefined behaviour , so , to preserve semantics the compiler CAN make this assumption .
This transformation is just as legal as : if ( ! p ) do1 ( ) ; if ( ! p ) do2 ( ) ; if do1 ( ) has no way of reaching p , transform to : if ( ! p ) { do1 ( ) ; do2 ( ) ; } Of course , if p is global , or otherwise reachable from do1 ( ) , this transformation is n't legal .
But , in this case , tun can be assumed non-NULL , and the optimization made , because the OTHER interpretation allows it as well ( undefined , eg .
better than turning your computer into a goat or something ) .</tokentext>
<sentencetext>You are confusing the two things --A "pointer" is not an "address".
It is not legal to dereference a pointer containing 0.
If "0" is a valid address, AND an object could be located there, it would still be necessary to refer to it by something other than "0".Now, it so happens that addresses are typically used as pointers, and "0" is simply not allowed as an object address.
Whichalso works.But, it is true that a dereference from 0 gives undefined behaviour,  so, to preserve semantics the compiler CAN make this assumption.
This transformation is just as legal as:if (!p) do1();if (!p) do2();if do1() has no way of reaching p, transform to:if (!p) {do1(); do2();}Of course, if p is global, or otherwise reachable from do1(), this transformation isn't legal.
But, in this case, tun can be assumed non-NULL, and the optimization made, because the OTHER interpretation allows it as well (undefined, eg.
better than turning your computer into a goat or something).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742365</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740637</id>
	<title>Re:Double standards</title>
	<author>Anonymous</author>
	<datestamp>1247930880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>GCC "optimizations" are one of the main reasons OpenBSD specifically is looking forward to replace it with PCC.<br>When optimizations keep you from knowing what a program will do, they have gone too far.</p></htmltext>
<tokenext>GCC " optimizations " are one of the main reasons OpenBSD specifically is looking forward to replace it with PCC.When optimizations keep you from knowing what a program will do , they have gone too far .</tokentext>
<sentencetext>GCC "optimizations" are one of the main reasons OpenBSD specifically is looking forward to replace it with PCC.When optimizations keep you from knowing what a program will do, they have gone too far.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739977</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740153</id>
	<title>Re:Wait, what?</title>
	<author>pdh11</author>
	<datestamp>1247926560000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><blockquote><div><p>Technically, however, the C standard allows tun-&gt;sk to be a valid address, so removing the test is a semantically-invalid optimisation.</p></div></blockquote><p>No. Technically, if tun is null, dereferencing it in the expression tun-&gt;sk invokes <i>undefined</i> behaviour -- <i>not</i> implementation-defined behaviour. It is perfectly valid to remove the test, because no strictly conforming code could tell the difference -- the game is already over once you've dereferenced a null pointer. This is a kernel bug (and not even, as Brad Spengler appears to be claiming, a new class of kernel bug); it's not a GCC bug.</p><p>But as other posters have said, it would indeed be a good security feature for GCC to warn when it does this.</p><p>Peter</p></div>
	</htmltext>
<tokenext>Technically , however , the C standard allows tun- &gt; sk to be a valid address , so removing the test is a semantically-invalid optimisation.No .
Technically , if tun is null , dereferencing it in the expression tun- &gt; sk invokes undefined behaviour -- not implementation-defined behaviour .
It is perfectly valid to remove the test , because no strictly conforming code could tell the difference -- the game is already over once you 've dereferenced a null pointer .
This is a kernel bug ( and not even , as Brad Spengler appears to be claiming , a new class of kernel bug ) ; it 's not a GCC bug.But as other posters have said , it would indeed be a good security feature for GCC to warn when it does this.Peter</tokentext>
<sentencetext>Technically, however, the C standard allows tun-&gt;sk to be a valid address, so removing the test is a semantically-invalid optimisation.No.
Technically, if tun is null, dereferencing it in the expression tun-&gt;sk invokes undefined behaviour -- not implementation-defined behaviour.
It is perfectly valid to remove the test, because no strictly conforming code could tell the difference -- the game is already over once you've dereferenced a null pointer.
This is a kernel bug (and not even, as Brad Spengler appears to be claiming, a new class of kernel bug); it's not a GCC bug.But as other posters have said, it would indeed be a good security feature for GCC to warn when it does this.Peter
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742411</id>
	<title>Re:Just like Linux</title>
	<author>Anonymous</author>
	<datestamp>1247945640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Minus its usefulness</htmltext>
<tokenext>Minus its usefulness</tokentext>
<sentencetext>Minus its usefulness</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739999</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740289</id>
	<title>Re:CFLAGS</title>
	<author>quintus\_horatius</author>
	<datestamp>1247927820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>All this means is that well-behaved packages (and users) won't accidentally exploit this bug, but it doesn't take away the fact that the <strong>kernel</strong> shouldn't allow the exploit.</htmltext>
<tokenext>All this means is that well-behaved packages ( and users ) wo n't accidentally exploit this bug , but it does n't take away the fact that the kernel should n't allow the exploit .</tokentext>
<sentencetext>All this means is that well-behaved packages (and users) won't accidentally exploit this bug, but it doesn't take away the fact that the kernel shouldn't allow the exploit.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740063</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741497</id>
	<title>Who is right?</title>
	<author>Anonymous</author>
	<datestamp>1247938380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>one guy blames compiler, other blames code, then another blames compiler, another blamdes code<nobr> <wbr></nobr>... repeat x 10....<br>all moderated informative,  WHOS RIGHT?</p></htmltext>
<tokenext>one guy blames compiler , other blames code , then another blames compiler , another blamdes code ... repeat x 10....all moderated informative , WHOS RIGHT ?</tokentext>
<sentencetext>one guy blames compiler, other blames code, then another blames compiler, another blamdes code ... repeat x 10....all moderated informative,  WHOS RIGHT?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741691</id>
	<title>Re:Serious bug in gcc?</title>
	<author>Anonymous</author>
	<datestamp>1247939940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Why do so many people think that "void * a = b-&gt;c" dereferences b? It takes the address of c in b and assigns it to a. It's only doing a pointer calculation: assigning an address of something to a pointer, it's not accessing any memory, so there is no way for a page fault or 'blow up' of any kind to occur.</p><p>It dereferencing the null pointer would 'blow up', then the exploit would not have worked because no code after the 'tun-&gt;sk' would be executed.</p></htmltext>
<tokenext>Why do so many people think that " void * a = b- &gt; c " dereferences b ?
It takes the address of c in b and assigns it to a. It 's only doing a pointer calculation : assigning an address of something to a pointer , it 's not accessing any memory , so there is no way for a page fault or 'blow up ' of any kind to occur.It dereferencing the null pointer would 'blow up ' , then the exploit would not have worked because no code after the 'tun- &gt; sk ' would be executed .</tokentext>
<sentencetext>Why do so many people think that "void * a = b-&gt;c" dereferences b?
It takes the address of c in b and assigns it to a. It's only doing a pointer calculation: assigning an address of something to a pointer, it's not accessing any memory, so there is no way for a page fault or 'blow up' of any kind to occur.It dereferencing the null pointer would 'blow up', then the exploit would not have worked because no code after the 'tun-&gt;sk' would be executed.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740087</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743895</id>
	<title>Re:Serious bug in gcc?</title>
	<author>Anonymous</author>
	<datestamp>1247915760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Bad bad.</p><p>Pointing NULL anywhere other than at binary zero causes enough code not to work that it is not a good idea (too much code tends to assume memset or static allocation initialized pointers to NULL these days).</p><p>On the last embedded platform I messed with, there were NO invalid addresses period. Pointers were 16 bits and I had 64 KB total RAM.</p></htmltext>
<tokenext>Bad bad.Pointing NULL anywhere other than at binary zero causes enough code not to work that it is not a good idea ( too much code tends to assume memset or static allocation initialized pointers to NULL these days ) .On the last embedded platform I messed with , there were NO invalid addresses period .
Pointers were 16 bits and I had 64 KB total RAM .</tokentext>
<sentencetext>Bad bad.Pointing NULL anywhere other than at binary zero causes enough code not to work that it is not a good idea (too much code tends to assume memset or static allocation initialized pointers to NULL these days).On the last embedded platform I messed with, there were NO invalid addresses period.
Pointers were 16 bits and I had 64 KB total RAM.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740413</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28744017</id>
	<title>I call shenanigans.</title>
	<author>argent</author>
	<datestamp>1247917080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>A comment on Reddit pointed out something interesting. He speculated that the reason the test was after the assignment is that the programmer was trying to follow the often recommended style of initializing your variables when you declare them. The kernel uses C89, which requires all declarations to be at the top of the function, before any code (other than initializers). Thus, he couldn't test for null before initializing.</i></p><p>You mean there was some orbital mind control laser preventing him from writing this?</p><blockquote><div><p> <tt>struct sock *sk = tun ? tun-&gt;sk : NULL;<nobr> <wbr></nobr>// initialize sk with tun-&gt;sk<br>...<br>if (!tun)<br>
&nbsp; &nbsp; return POLLERR;<nobr> <wbr></nobr>// if tun is NULL return error</tt></p></div> </blockquote><p>Or this?</p><blockquote><div><p> <tt>struct sock *sk;<br>...<br>if (!tun)<br>
&nbsp; &nbsp; return POLLERR;<nobr> <wbr></nobr>// if tun is NULL return error<br>
&nbsp; <br>sk = tun-&gt;sk;<nobr> <wbr></nobr>// initialize sk with tun-&gt;sk</tt></p></div> </blockquote><p>This was a simple oversight.</p></div>
	</htmltext>
<tokenext>A comment on Reddit pointed out something interesting .
He speculated that the reason the test was after the assignment is that the programmer was trying to follow the often recommended style of initializing your variables when you declare them .
The kernel uses C89 , which requires all declarations to be at the top of the function , before any code ( other than initializers ) .
Thus , he could n't test for null before initializing.You mean there was some orbital mind control laser preventing him from writing this ?
struct sock * sk = tun ?
tun- &gt; sk : NULL ; // initialize sk with tun- &gt; sk...if ( ! tun )     return POLLERR ; // if tun is NULL return error Or this ?
struct sock * sk ; ...if ( ! tun )     return POLLERR ; // if tun is NULL return error   sk = tun- &gt; sk ; // initialize sk with tun- &gt; sk This was a simple oversight .</tokentext>
<sentencetext>A comment on Reddit pointed out something interesting.
He speculated that the reason the test was after the assignment is that the programmer was trying to follow the often recommended style of initializing your variables when you declare them.
The kernel uses C89, which requires all declarations to be at the top of the function, before any code (other than initializers).
Thus, he couldn't test for null before initializing.You mean there was some orbital mind control laser preventing him from writing this?
struct sock *sk = tun ?
tun-&gt;sk : NULL; // initialize sk with tun-&gt;sk...if (!tun)
    return POLLERR; // if tun is NULL return error Or this?
struct sock *sk;...if (!tun)
    return POLLERR; // if tun is NULL return error
  sk = tun-&gt;sk; // initialize sk with tun-&gt;sk This was a simple oversight.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743473</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742541</id>
	<title>Re:Serious bug in gcc?</title>
	<author>Cacadril</author>
	<datestamp>1247946660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Why do so many people think that "void * a = b-&gt;c" dereferences b? It takes the address of c in b and assigns it to a. It's only doing a pointer calculation: assigning an address of something to a pointer, it's not accessing any memory</p></div><p>This is wrong. The code computes the address of 'b-&gt;c', <i>reads that memory location</i>, and stores the data it gets, into 'a'.</p><p>The comment would have been correct if the code had been "void *a = &amp;b-&gt;c;" In this case only the address of 'b-&gt;c' (which amounts to adding an offset to the contents of variable 'b') would have been loaded into variable 'a'. As it stands, the data stored in memory at that address is loaded into 'a'. The fact that 'a' is declared as a pointer does not change that. That only means that the data loaded from memory is assumed to be a valid pointer value (or NULL). This has the effect of determining how many bytes of register or stack space is used for the 'a' variable, 4 on 32-bit, 8 on 64-bit. The type declaration of the 'c' member of the 'typeof(*b)' struct determines how many bytes are read from memory.</p></div>
	</htmltext>
<tokenext>Why do so many people think that " void * a = b- &gt; c " dereferences b ?
It takes the address of c in b and assigns it to a. It 's only doing a pointer calculation : assigning an address of something to a pointer , it 's not accessing any memoryThis is wrong .
The code computes the address of 'b- &gt; c ' , reads that memory location , and stores the data it gets , into 'a'.The comment would have been correct if the code had been " void * a = &amp;b- &gt; c ; " In this case only the address of 'b- &gt; c ' ( which amounts to adding an offset to the contents of variable 'b ' ) would have been loaded into variable 'a' .
As it stands , the data stored in memory at that address is loaded into 'a' .
The fact that 'a ' is declared as a pointer does not change that .
That only means that the data loaded from memory is assumed to be a valid pointer value ( or NULL ) .
This has the effect of determining how many bytes of register or stack space is used for the 'a ' variable , 4 on 32-bit , 8 on 64-bit .
The type declaration of the 'c ' member of the 'typeof ( * b ) ' struct determines how many bytes are read from memory .</tokentext>
<sentencetext>Why do so many people think that "void * a = b-&gt;c" dereferences b?
It takes the address of c in b and assigns it to a. It's only doing a pointer calculation: assigning an address of something to a pointer, it's not accessing any memoryThis is wrong.
The code computes the address of 'b-&gt;c', reads that memory location, and stores the data it gets, into 'a'.The comment would have been correct if the code had been "void *a = &amp;b-&gt;c;" In this case only the address of 'b-&gt;c' (which amounts to adding an offset to the contents of variable 'b') would have been loaded into variable 'a'.
As it stands, the data stored in memory at that address is loaded into 'a'.
The fact that 'a' is declared as a pointer does not change that.
That only means that the data loaded from memory is assumed to be a valid pointer value (or NULL).
This has the effect of determining how many bytes of register or stack space is used for the 'a' variable, 4 on 32-bit, 8 on 64-bit.
The type declaration of the 'c' member of the 'typeof(*b)' struct determines how many bytes are read from memory.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741691</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742321</id>
	<title>Re:Serious bug in gcc?</title>
	<author>RightSaidFred99</author>
	<datestamp>1247944920000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext>Because... so many people know the C language?  And you clearly don't?</htmltext>
<tokenext>Because... so many people know the C language ?
And you clearly do n't ?</tokentext>
<sentencetext>Because... so many people know the C language?
And you clearly don't?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741691</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741425</id>
	<title>Running a static checker on the Linux kernel?</title>
	<author>Anonymous</author>
	<datestamp>1247937660000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>
Isn't someone running a static checker on the Linux kernel?  There are commercial tools which will find code that can dereference NULL.  However, there aren't free tools that will do this.</p></htmltext>
<tokenext>Is n't someone running a static checker on the Linux kernel ?
There are commercial tools which will find code that can dereference NULL .
However , there are n't free tools that will do this .</tokentext>
<sentencetext>
Isn't someone running a static checker on the Linux kernel?
There are commercial tools which will find code that can dereference NULL.
However, there aren't free tools that will do this.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741625</id>
	<title>Re:Wait, what?</title>
	<author>ext42fs</author>
	<datestamp>1247939400000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>I think the compiler is correct. If tun is null, then tun-&gt;sk is undefined and the compiler can do what even optimization it want.</p><p>So when the compiler see tun-&gt;sk it can assume that tun is not null, and do the optimization, because IF tun is null, then the program is invoked undefined behavier, which the compiler don't have to preserve/handle. (How do you keep the semantic of an undefined program??)</p></div><p>The compiler is a complete asshole for deliberately optimizing a too late NULL check away instead of screaming "possibly dereferencing NULL" or something.</p></div>
	</htmltext>
<tokenext>I think the compiler is correct .
If tun is null , then tun- &gt; sk is undefined and the compiler can do what even optimization it want.So when the compiler see tun- &gt; sk it can assume that tun is not null , and do the optimization , because IF tun is null , then the program is invoked undefined behavier , which the compiler do n't have to preserve/handle .
( How do you keep the semantic of an undefined program ? ?
) The compiler is a complete asshole for deliberately optimizing a too late NULL check away instead of screaming " possibly dereferencing NULL " or something .</tokentext>
<sentencetext>I think the compiler is correct.
If tun is null, then tun-&gt;sk is undefined and the compiler can do what even optimization it want.So when the compiler see tun-&gt;sk it can assume that tun is not null, and do the optimization, because IF tun is null, then the program is invoked undefined behavier, which the compiler don't have to preserve/handle.
(How do you keep the semantic of an undefined program??
)The compiler is a complete asshole for deliberately optimizing a too late NULL check away instead of screaming "possibly dereferencing NULL" or something.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740137</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740385</id>
	<title>Re:Wait, what?</title>
	<author>MadShark</author>
	<datestamp>1247928840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Wouldn't lint catch typically catch this sort of problem(possible use of a NULL pointer warning)?</p></htmltext>
<tokenext>Would n't lint catch typically catch this sort of problem ( possible use of a NULL pointer warning ) ?</tokentext>
<sentencetext>Wouldn't lint catch typically catch this sort of problem(possible use of a NULL pointer warning)?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741275</id>
	<title>Re:Wait, what?</title>
	<author>Athanasius</author>
	<datestamp>1247936340000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><blockquote><div><p>This ought to be crashing at the sk = tun-&gt;sk line, because the structure is smaller than a page, and page 0 is mapped no-access (I assume Linux does this; it's been standard practice in most operating systems for a couple of decades to protect against NULL-pointer dereferencing).</p></div></blockquote><p>If you actually read the exploit code (see: <a href="http://grsecurity.net/~spender/cheddar\_bay.tgz" title="grsecurity.net" rel="nofollow">http://grsecurity.net/~spender/cheddar\_bay.tgz</a> [grsecurity.net]) the thing that really enables this exploit is one of two ways to map page zero.  One of these seems to be a flaw with SELinux (either with the default settings and/or how the default config commonly ships) or using personality(2) to select a personality that explicitly allows this.</p><p>From the exploit for the personality case:</p><blockquote><div><p> <tt>int main(void)<br>{<br>
&nbsp; &nbsp; &nbsp; &nbsp; int ret;<br>
&nbsp; &nbsp; &nbsp; &nbsp; struct stat fstat;<br>
&nbsp; <br>
&nbsp; &nbsp; &nbsp; &nbsp; ret = personality(PER\_SVR4);<br>
&nbsp; <br>
&nbsp; &nbsp; &nbsp; &nbsp; if (ret == -1) {<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; fprintf(stderr, "Unable to set personality!\n");<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return 0;<br>
&nbsp; &nbsp; &nbsp; &nbsp; }</tt></p></div> </blockquote><p>Note you do need some setuid root program even with this (from my reading of the exploit code).</p><p>In the SELinux case "it just works" without needing the setuid program it seems.</p></div>
	</htmltext>
<tokenext>This ought to be crashing at the sk = tun- &gt; sk line , because the structure is smaller than a page , and page 0 is mapped no-access ( I assume Linux does this ; it 's been standard practice in most operating systems for a couple of decades to protect against NULL-pointer dereferencing ) .If you actually read the exploit code ( see : http : //grsecurity.net/ ~ spender/cheddar \ _bay.tgz [ grsecurity.net ] ) the thing that really enables this exploit is one of two ways to map page zero .
One of these seems to be a flaw with SELinux ( either with the default settings and/or how the default config commonly ships ) or using personality ( 2 ) to select a personality that explicitly allows this.From the exploit for the personality case : int main ( void ) {         int ret ;         struct stat fstat ;           ret = personality ( PER \ _SVR4 ) ;           if ( ret = = -1 ) {                 fprintf ( stderr , " Unable to set personality ! \ n " ) ;                 return 0 ;         } Note you do need some setuid root program even with this ( from my reading of the exploit code ) .In the SELinux case " it just works " without needing the setuid program it seems .</tokentext>
<sentencetext>This ought to be crashing at the sk = tun-&gt;sk line, because the structure is smaller than a page, and page 0 is mapped no-access (I assume Linux does this; it's been standard practice in most operating systems for a couple of decades to protect against NULL-pointer dereferencing).If you actually read the exploit code (see: http://grsecurity.net/~spender/cheddar\_bay.tgz [grsecurity.net]) the thing that really enables this exploit is one of two ways to map page zero.
One of these seems to be a flaw with SELinux (either with the default settings and/or how the default config commonly ships) or using personality(2) to select a personality that explicitly allows this.From the exploit for the personality case: int main(void){
        int ret;
        struct stat fstat;
  
        ret = personality(PER\_SVR4);
  
        if (ret == -1) {
                fprintf(stderr, "Unable to set personality!\n");
                return 0;
        } Note you do need some setuid root program even with this (from my reading of the exploit code).In the SELinux case "it just works" without needing the setuid program it seems.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742221</id>
	<title>Re:Double standards</title>
	<author>RightSaidFred99</author>
	<datestamp>1247944080000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Oh nonsense.  You have no idea of the root cause of most Windows exploits.  In fact, it would be interesting if you would get in your Way Back machine and point out the last time windows had an F'ING KERNEL exploit.  Jesus.</p><p>At the OS level, anyone with half a brain can guess that Linux is probably less secure than Windows.  It's all the shit that runs on Windows that has the issue.  Yet you apologists all come on and act like any kind of Linux flaw is just some odd anomaly and easily explained away.</p><p>What's worse, how long will this exploit live in the wild?  You'll all foam at the mouth how quickly it will be patch.  OK.  That's nice and all, but how long until it's disseminated on say 90\% of Linux machines exhibiting the flaw?  And I'm sure, being Linux, this won't take a reboot right?  (I'm joking on that last one - of course it will).</p><p>Double standard indeed.</p></htmltext>
<tokenext>Oh nonsense .
You have no idea of the root cause of most Windows exploits .
In fact , it would be interesting if you would get in your Way Back machine and point out the last time windows had an F'ING KERNEL exploit .
Jesus.At the OS level , anyone with half a brain can guess that Linux is probably less secure than Windows .
It 's all the shit that runs on Windows that has the issue .
Yet you apologists all come on and act like any kind of Linux flaw is just some odd anomaly and easily explained away.What 's worse , how long will this exploit live in the wild ?
You 'll all foam at the mouth how quickly it will be patch .
OK. That 's nice and all , but how long until it 's disseminated on say 90 \ % of Linux machines exhibiting the flaw ?
And I 'm sure , being Linux , this wo n't take a reboot right ?
( I 'm joking on that last one - of course it will ) .Double standard indeed .</tokentext>
<sentencetext>Oh nonsense.
You have no idea of the root cause of most Windows exploits.
In fact, it would be interesting if you would get in your Way Back machine and point out the last time windows had an F'ING KERNEL exploit.
Jesus.At the OS level, anyone with half a brain can guess that Linux is probably less secure than Windows.
It's all the shit that runs on Windows that has the issue.
Yet you apologists all come on and act like any kind of Linux flaw is just some odd anomaly and easily explained away.What's worse, how long will this exploit live in the wild?
You'll all foam at the mouth how quickly it will be patch.
OK.  That's nice and all, but how long until it's disseminated on say 90\% of Linux machines exhibiting the flaw?
And I'm sure, being Linux, this won't take a reboot right?
(I'm joking on that last one - of course it will).Double standard indeed.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739977</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740141</id>
	<title>Re:Serious bug in gcc?</title>
	<author>Bananenrepublik</author>
	<datestamp>1247926380000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>They were writing nonsense.  GCC makes use of the fact that in the C language any pointer that was dereferenced can't be NULL (this is made explicit in the standard).  People use C as a high-level assembly where these assumptions don't hold.  This is why code that doesn't assume this breaks.  This issue came up a few months ago on the GCC lists, where an embedded developer pointed out that he regularly maps memory to the address 0x0, thereby running into issues with this assumption in the optimizers.  The GCC developers introduced a command-line flag which tells the computer to not make that assumption, therefore allowing the compiler to be used even in environments where NULL pointers can be valid.</p><p>Now, the exploit uses this feature of the compiler (or the C language, if you will) to get the kernel into an unspecified state (which is then exploited) -- the NULL pointer check will be "correctly" optimized away.  But in order to do this it first has to make sure that the pointer dereference preceding the NULL pointer check doesn't trap.  This needs some mucking around with SELinux, namely one has to map memory to 0x0.</p><p>This is a beautiful exploit, which nicely demonstrates how complex interplay between parts can show unforeseen consequences.  Linux fixes this by using the aforementioned new compiler option to not have the NULL pointer check optimized away.</p></htmltext>
<tokenext>They were writing nonsense .
GCC makes use of the fact that in the C language any pointer that was dereferenced ca n't be NULL ( this is made explicit in the standard ) .
People use C as a high-level assembly where these assumptions do n't hold .
This is why code that does n't assume this breaks .
This issue came up a few months ago on the GCC lists , where an embedded developer pointed out that he regularly maps memory to the address 0x0 , thereby running into issues with this assumption in the optimizers .
The GCC developers introduced a command-line flag which tells the computer to not make that assumption , therefore allowing the compiler to be used even in environments where NULL pointers can be valid.Now , the exploit uses this feature of the compiler ( or the C language , if you will ) to get the kernel into an unspecified state ( which is then exploited ) -- the NULL pointer check will be " correctly " optimized away .
But in order to do this it first has to make sure that the pointer dereference preceding the NULL pointer check does n't trap .
This needs some mucking around with SELinux , namely one has to map memory to 0x0.This is a beautiful exploit , which nicely demonstrates how complex interplay between parts can show unforeseen consequences .
Linux fixes this by using the aforementioned new compiler option to not have the NULL pointer check optimized away .</tokentext>
<sentencetext>They were writing nonsense.
GCC makes use of the fact that in the C language any pointer that was dereferenced can't be NULL (this is made explicit in the standard).
People use C as a high-level assembly where these assumptions don't hold.
This is why code that doesn't assume this breaks.
This issue came up a few months ago on the GCC lists, where an embedded developer pointed out that he regularly maps memory to the address 0x0, thereby running into issues with this assumption in the optimizers.
The GCC developers introduced a command-line flag which tells the computer to not make that assumption, therefore allowing the compiler to be used even in environments where NULL pointers can be valid.Now, the exploit uses this feature of the compiler (or the C language, if you will) to get the kernel into an unspecified state (which is then exploited) -- the NULL pointer check will be "correctly" optimized away.
But in order to do this it first has to make sure that the pointer dereference preceding the NULL pointer check doesn't trap.
This needs some mucking around with SELinux, namely one has to map memory to 0x0.This is a beautiful exploit, which nicely demonstrates how complex interplay between parts can show unforeseen consequences.
Linux fixes this by using the aforementioned new compiler option to not have the NULL pointer check optimized away.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740019</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739967</id>
	<title>DRM is defective by design.</title>
	<author>BPPG</author>
	<datestamp>1247924220000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>I think that tag is mostly reserved for DRM related news...</p><p>And I have seen news about linux DRM modules also tagged that.</p></htmltext>
<tokenext>I think that tag is mostly reserved for DRM related news...And I have seen news about linux DRM modules also tagged that .</tokentext>
<sentencetext>I think that tag is mostly reserved for DRM related news...And I have seen news about linux DRM modules also tagged that.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739929</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740713</id>
	<title>Re:CFLAGS</title>
	<author>Anonymous</author>
	<datestamp>1247931540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'd just like to say this to all the wankers out there who hate Gentoo because they have this weird prejudiced view that they're all a bunch of over-optimizing speed freaks:</p><p><div class="quote"><p>CFLAGS+= -fno-delete-null-pointer-checks</p></div><p>Yes, that would be a Gentoo user using Gentoo's source-based package system to REDUCE an optimization and make the system more secure.</p><p>And that's why I like Gentoo, and why the haters can, in fact, go suck it.</p></div>
	</htmltext>
<tokenext>I 'd just like to say this to all the wankers out there who hate Gentoo because they have this weird prejudiced view that they 're all a bunch of over-optimizing speed freaks : CFLAGS + = -fno-delete-null-pointer-checksYes , that would be a Gentoo user using Gentoo 's source-based package system to REDUCE an optimization and make the system more secure.And that 's why I like Gentoo , and why the haters can , in fact , go suck it .</tokentext>
<sentencetext>I'd just like to say this to all the wankers out there who hate Gentoo because they have this weird prejudiced view that they're all a bunch of over-optimizing speed freaks:CFLAGS+= -fno-delete-null-pointer-checksYes, that would be a Gentoo user using Gentoo's source-based package system to REDUCE an optimization and make the system more secure.And that's why I like Gentoo, and why the haters can, in fact, go suck it.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740063</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742365</id>
	<title>Re:Wait, what?</title>
	<author>sjames</author>
	<datestamp>1247945160000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Arguably the compiler is wrong because it's (obviously) not actually impossible for address 0 to refer to valid memory however against convention and best practices that may be. The very existence of this problem proves that the compiler can NOT assume that tun is not null.</p></htmltext>
<tokenext>Arguably the compiler is wrong because it 's ( obviously ) not actually impossible for address 0 to refer to valid memory however against convention and best practices that may be .
The very existence of this problem proves that the compiler can NOT assume that tun is not null .</tokentext>
<sentencetext>Arguably the compiler is wrong because it's (obviously) not actually impossible for address 0 to refer to valid memory however against convention and best practices that may be.
The very existence of this problem proves that the compiler can NOT assume that tun is not null.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740137</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742931</id>
	<title>Bullshit</title>
	<author>omb</author>
	<datestamp>1247950200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The compiler cannot know tun == 0, which is what the "if (!tun)" is testing (BTW as a pun), and the code is clearly crackpot.<br><br>Any idiot, who tries to defend GCC.&amp;#160;or "undefined" to justify optimisation removing this 0-test needs to spend the rest of their lives writing absolute machine code, in HEX, as they clearly do not understand high-level languages.<br><br>If, and only if "tun = 0; if (!tun)<nobr> <wbr></nobr>..." be optimised, since NULL is not guarented to be 0.<br><br>If  anyone wrote this code, as opposed to it getting patched in, they need their coding finger cut off, since it is not only dangerous, manifestly daft, stupid, BUT also a race unless LOCKED+INTERRUPTS off.<br><br>Clearly this code did not get enough competent eyes.</htmltext>
<tokenext>The compiler can not know tun = = 0 , which is what the " if ( ! tun ) " is testing ( BTW as a pun ) , and the code is clearly crackpot.Any idiot , who tries to defend GCC.   or " undefined " to justify optimisation removing this 0-test needs to spend the rest of their lives writing absolute machine code , in HEX , as they clearly do not understand high-level languages.If , and only if " tun = 0 ; if ( ! tun ) ... " be optimised , since NULL is not guarented to be 0.If anyone wrote this code , as opposed to it getting patched in , they need their coding finger cut off , since it is not only dangerous , manifestly daft , stupid , BUT also a race unless LOCKED + INTERRUPTS off.Clearly this code did not get enough competent eyes .</tokentext>
<sentencetext>The compiler cannot know tun == 0, which is what the "if (!tun)" is testing (BTW as a pun), and the code is clearly crackpot.Any idiot, who tries to defend GCC. or "undefined" to justify optimisation removing this 0-test needs to spend the rest of their lives writing absolute machine code, in HEX, as they clearly do not understand high-level languages.If, and only if "tun = 0; if (!tun) ..." be optimised, since NULL is not guarented to be 0.If  anyone wrote this code, as opposed to it getting patched in, they need their coding finger cut off, since it is not only dangerous, manifestly daft, stupid, BUT also a race unless LOCKED+INTERRUPTS off.Clearly this code did not get enough competent eyes.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740137</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741251</id>
	<title>Re:I always disable those</title>
	<author>Anonymous</author>
	<datestamp>1247936220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Well the exploit seems to also works without the security modules. http://www.youtube.com/watch?v=UdkpJ13e6Z0&amp;fmt=35</p><p>Security modules are just way to create more fine-tuned restriction policies but that's no silver bullet if you have no idea of how it works.</p></htmltext>
<tokenext>Well the exploit seems to also works without the security modules .
http : //www.youtube.com/watch ? v = UdkpJ13e6Z0&amp;fmt = 35Security modules are just way to create more fine-tuned restriction policies but that 's no silver bullet if you have no idea of how it works .</tokentext>
<sentencetext>Well the exploit seems to also works without the security modules.
http://www.youtube.com/watch?v=UdkpJ13e6Z0&amp;fmt=35Security modules are just way to create more fine-tuned restriction policies but that's no silver bullet if you have no idea of how it works.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739985</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740137</id>
	<title>Re:Wait, what?</title>
	<author>TheSunborn</author>
	<datestamp>1247926320000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>I think the compiler is correct. If tun is null, then tun-&gt;sk is undefined and the compiler can do what even optimization it want.</p><p>So when the compiler see tun-&gt;sk it can assume that tun is not null, and do the optimization, because IF tun is null, then the program is invoked undefined behavier, which the compiler don't have to preserve/handle. (How do you keep the semantic of an undefined program??)</p></htmltext>
<tokenext>I think the compiler is correct .
If tun is null , then tun- &gt; sk is undefined and the compiler can do what even optimization it want.So when the compiler see tun- &gt; sk it can assume that tun is not null , and do the optimization , because IF tun is null , then the program is invoked undefined behavier , which the compiler do n't have to preserve/handle .
( How do you keep the semantic of an undefined program ? ?
)</tokentext>
<sentencetext>I think the compiler is correct.
If tun is null, then tun-&gt;sk is undefined and the compiler can do what even optimization it want.So when the compiler see tun-&gt;sk it can assume that tun is not null, and do the optimization, because IF tun is null, then the program is invoked undefined behavier, which the compiler don't have to preserve/handle.
(How do you keep the semantic of an undefined program??
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28746737</id>
	<title>Re:Double standards</title>
	<author>x2A</author>
	<datestamp>1248004080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>"And I'm sure, being Linux, this won't take a reboot right? (I'm joking on that last one - of course it will)"</i></p><p>Not heard of ksplice?<nobr> <wbr></nobr>:-p</p><p><i>"all foam at the mouth how quickly it will be patch. OK. That's nice and all, but how long until it's disseminated on say 90\% of Linux machines exhibiting the flaw?"</i></p><p>I'd say fairly quickly. Anyone running a 2.6.30 kernel is someone who's updating the kernel themselves rather than relying on distro updates, as I doubt 2.6.30 is too common amongst distros at the moment, and that being so, it should be rare that the bug ever really gets out amongst the masses. Someone who's keeping their kernel that updated will probably continue doing so.</p><p>It's still not good, sure, but I doubt it's really going to be devastating.</p></htmltext>
<tokenext>" And I 'm sure , being Linux , this wo n't take a reboot right ?
( I 'm joking on that last one - of course it will ) " Not heard of ksplice ?
: -p " all foam at the mouth how quickly it will be patch .
OK. That 's nice and all , but how long until it 's disseminated on say 90 \ % of Linux machines exhibiting the flaw ?
" I 'd say fairly quickly .
Anyone running a 2.6.30 kernel is someone who 's updating the kernel themselves rather than relying on distro updates , as I doubt 2.6.30 is too common amongst distros at the moment , and that being so , it should be rare that the bug ever really gets out amongst the masses .
Someone who 's keeping their kernel that updated will probably continue doing so.It 's still not good , sure , but I doubt it 's really going to be devastating .</tokentext>
<sentencetext>"And I'm sure, being Linux, this won't take a reboot right?
(I'm joking on that last one - of course it will)"Not heard of ksplice?
:-p"all foam at the mouth how quickly it will be patch.
OK. That's nice and all, but how long until it's disseminated on say 90\% of Linux machines exhibiting the flaw?
"I'd say fairly quickly.
Anyone running a 2.6.30 kernel is someone who's updating the kernel themselves rather than relying on distro updates, as I doubt 2.6.30 is too common amongst distros at the moment, and that being so, it should be rare that the bug ever really gets out amongst the masses.
Someone who's keeping their kernel that updated will probably continue doing so.It's still not good, sure, but I doubt it's really going to be devastating.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742221</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28750265</id>
	<title>Re:Double standards</title>
	<author>Anonymous</author>
	<datestamp>1247998800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>I'll stop bashing Pulse Audio when it works. As it happens, that garbage just likes to break sound on just about every system I've seen it implemented on.
<br> <br>
And don't feed me "its the distros fault for not implementing it" bullshit. If that were true it wouldn't break on EVERY distribution I've seen it run on, because it is so ready for production deployment.
<br> <br>
I'll stick with ALSA or OSSv4, thanks, they're actually quality sound systems.</htmltext>
<tokenext>I 'll stop bashing Pulse Audio when it works .
As it happens , that garbage just likes to break sound on just about every system I 've seen it implemented on .
And do n't feed me " its the distros fault for not implementing it " bullshit .
If that were true it would n't break on EVERY distribution I 've seen it run on , because it is so ready for production deployment .
I 'll stick with ALSA or OSSv4 , thanks , they 're actually quality sound systems .</tokentext>
<sentencetext>I'll stop bashing Pulse Audio when it works.
As it happens, that garbage just likes to break sound on just about every system I've seen it implemented on.
And don't feed me "its the distros fault for not implementing it" bullshit.
If that were true it wouldn't break on EVERY distribution I've seen it run on, because it is so ready for production deployment.
I'll stick with ALSA or OSSv4, thanks, they're actually quality sound systems.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742507</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739985</id>
	<title>I always disable those</title>
	<author>brunes69</author>
	<datestamp>1247924400000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>I always disable those security modules as they always end up to incompatibilities and other erratic behavior in software.</p><p>Exactly what do they do anyway?</p></htmltext>
<tokenext>I always disable those security modules as they always end up to incompatibilities and other erratic behavior in software.Exactly what do they do anyway ?</tokentext>
<sentencetext>I always disable those security modules as they always end up to incompatibilities and other erratic behavior in software.Exactly what do they do anyway?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740127</id>
	<title>Linus, you Rookie !!</title>
	<author>Anonymous</author>
	<datestamp>1247926200000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Who but a rookie does this in a kernel?  Cut and paste kernel soruces is not a good idea, Linus, you rookie !!</p></htmltext>
<tokenext>Who but a rookie does this in a kernel ?
Cut and paste kernel soruces is not a good idea , Linus , you rookie !
!</tokentext>
<sentencetext>Who but a rookie does this in a kernel?
Cut and paste kernel soruces is not a good idea, Linus, you rookie !
!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742507</id>
	<title>Re:Double standards</title>
	<author>Cyberax</author>
	<datestamp>1247946360000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Nope. PulseAudio is NOT necessary to trigger this flaw. Read the exploit source code.</p><p>PS: I hate PulseAudio bashing.</p></htmltext>
<tokenext>Nope .
PulseAudio is NOT necessary to trigger this flaw .
Read the exploit source code.PS : I hate PulseAudio bashing .</tokentext>
<sentencetext>Nope.
PulseAudio is NOT necessary to trigger this flaw.
Read the exploit source code.PS: I hate PulseAudio bashing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739977</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739929</id>
	<title>Double standards</title>
	<author>Anonymous</author>
	<datestamp>1247923560000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>If this had been Windows, the article would have been tagged defectivebydesign.</p></htmltext>
<tokenext>If this had been Windows , the article would have been tagged defectivebydesign .</tokentext>
<sentencetext>If this had been Windows, the article would have been tagged defectivebydesign.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743559</id>
	<title>Re:What's kept me from bothering with Linux.</title>
	<author>armanox</author>
	<datestamp>1247912700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>And what software "requires" a kernel recompile?  Most software that you compile will require kernel headers that match the running kernel, but, I haven't seen any software in the past 10 years that requires a kernel recompile.</htmltext>
<tokenext>And what software " requires " a kernel recompile ?
Most software that you compile will require kernel headers that match the running kernel , but , I have n't seen any software in the past 10 years that requires a kernel recompile .</tokentext>
<sentencetext>And what software "requires" a kernel recompile?
Most software that you compile will require kernel headers that match the running kernel, but, I haven't seen any software in the past 10 years that requires a kernel recompile.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742051</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741431</id>
	<title>Re:I always disable those</title>
	<author>RiotingPacifist</author>
	<datestamp>1247937720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Your doing it wrong! They restrict programs to what they should be doing, ofc it depends on how well they are configured (e.g ive never seen anybody notice apparmor on ubuntu, but plenty of people bitch about selinux on fedora (even though it has stopped in the wild vulnerabilities)).</p><p>We agree that running a program as root where it can do anything is a bad idea, follow the idea through and you shouldn't let a network daemon access to your home, a web browser shouldn't be writing anything to<nobr> <wbr></nobr>/etc. The idea of security modules is great, atm the problem is that its either to hard for your average user to understand what's going on or security experts claim it cant do enough, but once the interaction with them is perfected your average user should benefit significantly as even relatively unsafe software (firefox,sendmail,etc) will be unexploitable.</p></htmltext>
<tokenext>Your doing it wrong !
They restrict programs to what they should be doing , ofc it depends on how well they are configured ( e.g ive never seen anybody notice apparmor on ubuntu , but plenty of people bitch about selinux on fedora ( even though it has stopped in the wild vulnerabilities ) ) .We agree that running a program as root where it can do anything is a bad idea , follow the idea through and you should n't let a network daemon access to your home , a web browser should n't be writing anything to /etc .
The idea of security modules is great , atm the problem is that its either to hard for your average user to understand what 's going on or security experts claim it cant do enough , but once the interaction with them is perfected your average user should benefit significantly as even relatively unsafe software ( firefox,sendmail,etc ) will be unexploitable .</tokentext>
<sentencetext>Your doing it wrong!
They restrict programs to what they should be doing, ofc it depends on how well they are configured (e.g ive never seen anybody notice apparmor on ubuntu, but plenty of people bitch about selinux on fedora (even though it has stopped in the wild vulnerabilities)).We agree that running a program as root where it can do anything is a bad idea, follow the idea through and you shouldn't let a network daemon access to your home, a web browser shouldn't be writing anything to /etc.
The idea of security modules is great, atm the problem is that its either to hard for your average user to understand what's going on or security experts claim it cant do enough, but once the interaction with them is perfected your average user should benefit significantly as even relatively unsafe software (firefox,sendmail,etc) will be unexploitable.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739985</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740087</id>
	<title>Re:Serious bug in gcc?</title>
	<author>dakkar</author>
	<datestamp>1247925900000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>The description given by SANS is a bit misleading. What I believe is happening is:</p><ol><li>1) <tt>tun</tt> is derefenced during the assignment to <tt>sk</tt> </li><li>2) if <tt>tun</tt> were <tt>NULL</tt>, the dereferencing would blow up the process</li><li>3) so the <tt>if (!tun)</tt> will always be false if we get there (says the compiler)</li></ol><p>Since point 2 is mostly true, the compiler is not completely wrong to assume point 3</p><p>As Spengler says, a bigger problem is that loading SELinux (or, it looks like, most other security modules) causes the <tt>NULL</tt> dereference protection to be disabled.</p></htmltext>
<tokenext>The description given by SANS is a bit misleading .
What I believe is happening is : 1 ) tun is derefenced during the assignment to sk 2 ) if tun were NULL , the dereferencing would blow up the process3 ) so the if ( ! tun ) will always be false if we get there ( says the compiler ) Since point 2 is mostly true , the compiler is not completely wrong to assume point 3As Spengler says , a bigger problem is that loading SELinux ( or , it looks like , most other security modules ) causes the NULL dereference protection to be disabled .</tokentext>
<sentencetext>The description given by SANS is a bit misleading.
What I believe is happening is:1) tun is derefenced during the assignment to sk 2) if tun were NULL, the dereferencing would blow up the process3) so the if (!tun) will always be false if we get there (says the compiler)Since point 2 is mostly true, the compiler is not completely wrong to assume point 3As Spengler says, a bigger problem is that loading SELinux (or, it looks like, most other security modules) causes the NULL dereference protection to be disabled.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740019</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740019</id>
	<title>Serious bug in gcc?</title>
	<author>Anonymous</author>
	<datestamp>1247925000000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>The explanation given by the SANS Internet Storm Center seems strange. Firstly, the code they provide as an example shows one variable being assigned "sk" and then another variable being checked "tun". I think the "if" statement should be checking "sk" and not "tun". Secondly, the assignment could be a perfectly valid assignment of null; "tun-&gt;sk" could indeed be null. The compiler should certainly not optimize out the if statement just because the variable has already been assigned. This would be a major fault in the compiler.<br>Perhaps they have just oversimplified to the point of writing nonsense...</p></htmltext>
<tokenext>The explanation given by the SANS Internet Storm Center seems strange .
Firstly , the code they provide as an example shows one variable being assigned " sk " and then another variable being checked " tun " .
I think the " if " statement should be checking " sk " and not " tun " .
Secondly , the assignment could be a perfectly valid assignment of null ; " tun- &gt; sk " could indeed be null .
The compiler should certainly not optimize out the if statement just because the variable has already been assigned .
This would be a major fault in the compiler.Perhaps they have just oversimplified to the point of writing nonsense.. .</tokentext>
<sentencetext>The explanation given by the SANS Internet Storm Center seems strange.
Firstly, the code they provide as an example shows one variable being assigned "sk" and then another variable being checked "tun".
I think the "if" statement should be checking "sk" and not "tun".
Secondly, the assignment could be a perfectly valid assignment of null; "tun-&gt;sk" could indeed be null.
The compiler should certainly not optimize out the if statement just because the variable has already been assigned.
This would be a major fault in the compiler.Perhaps they have just oversimplified to the point of writing nonsense...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740597</id>
	<title>Re:Double standards</title>
	<author>Anonymous</author>
	<datestamp>1247930640000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>To be fair if it was windows we'd never know which bit of the code was exploitable or why just that there was an exploit after all we cant SEE their source.
<br> <br>
Good news is that this will be fixed in 2.30.2 in the next month instead of left to be fixed in windows 2012  if ever...</htmltext>
<tokenext>To be fair if it was windows we 'd never know which bit of the code was exploitable or why just that there was an exploit after all we cant SEE their source .
Good news is that this will be fixed in 2.30.2 in the next month instead of left to be fixed in windows 2012 if ever.. .</tokentext>
<sentencetext>To be fair if it was windows we'd never know which bit of the code was exploitable or why just that there was an exploit after all we cant SEE their source.
Good news is that this will be fixed in 2.30.2 in the next month instead of left to be fixed in windows 2012  if ever...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739981</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742153</id>
	<title>No, it's a compiler bug.  (test code)</title>
	<author>qieurowfhbvdklsj</author>
	<datestamp>1247943660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Here's a simple test program.  Compare the output when compiled with "gcc -o test test.c" to the output with "gcc -O2 -o test test.c".  I used gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5)</p><p>(Wow, the "preview" is ruining the formatting of this code.)</p><p>#include &lt;stdlib.h&gt;<br>#include &lt;unistd.h&gt;<br>#include &lt;stdio.h&gt;<br>#include &lt;math.h&gt;<br>#include &lt;string.h&gt;<br>#include &lt;sys/mman.h&gt;<br>#include &lt;sys/types.h&gt;<br>#include &lt;sys/stat.h&gt;<br>#include &lt;fcntl.h&gt;<br>#include &lt;errno.h&gt;</p><p>int main () {</p><p>
&nbsp; &nbsp; int fd;</p><p>
&nbsp; &nbsp; char *string = "  This text was read from a null pointer!\n";<br>
&nbsp; &nbsp; int length = strlen(string);</p><p>
&nbsp; &nbsp; char *pointer;<nobr> <wbr></nobr>/* Create a simple file... */<br>
&nbsp; &nbsp; fd = open("random\_nonexistant\_file", O\_CREAT | O\_RDWR | O\_TRUNC, 0666);<br>
&nbsp; &nbsp; write(fd, string, length);<nobr> <wbr></nobr>/* mmap the file to address zero */<br>
&nbsp; &nbsp; pointer = mmap(0, 4096, PROT\_READ | PROT\_WRITE, MAP\_SHARED | MAP\_FIXED, fd, 0)<br>;<nobr> <wbr></nobr>/* note: gcc optimizer doesn't know that the return value was null */<nobr> <wbr></nobr>/* Let's dereference that pointer and write to it! */</p><p>
&nbsp; &nbsp; pointer[0] = 42;<nobr> <wbr></nobr>/* Then we'll display it, but not using printf<br>
&nbsp; &nbsp; since it refuses to print from null pointers. */</p><p>
&nbsp; &nbsp; write(1, pointer, length);<nobr> <wbr></nobr>/* Also print the pointer value, just to make sure it is null. */</p><p>
&nbsp; &nbsp; printf("Pointer address: \%d\n", (int) pointer);<nobr> <wbr></nobr>/* Now let's find out if GCC thinks the pointer could possibly be null... */</p><p>
&nbsp; &nbsp; if (pointer == 0) {<br>
&nbsp; &nbsp; &nbsp; &nbsp; printf("The pointer is null!\n");<br>
&nbsp; &nbsp; } else {<br>
&nbsp; &nbsp; &nbsp; &nbsp; printf("The pointer is not null!\n");<br>
&nbsp; &nbsp; };</p><p>};</p><p>Either way, the pointer is displayed to be zero, but when you run the unoptomized version, it correctly states that the pointer is null, but the optimized version will tell you that it isn't null.  When optimization changes the behavior of a functional program, it is clearly doing the wrong thing.</p></htmltext>
<tokenext>Here 's a simple test program .
Compare the output when compiled with " gcc -o test test.c " to the output with " gcc -O2 -o test test.c " .
I used gcc version 4.3.2 ( Gentoo 4.3.2-r3 p1.6 , pie-10.1.5 ) ( Wow , the " preview " is ruining the formatting of this code .
) # include # include # include # include # include # include # include # include # include # include int main ( ) {     int fd ;     char * string = " This text was read from a null pointer ! \ n " ;     int length = strlen ( string ) ;     char * pointer ; / * Create a simple file... * /     fd = open ( " random \ _nonexistant \ _file " , O \ _CREAT | O \ _RDWR | O \ _TRUNC , 0666 ) ;     write ( fd , string , length ) ; / * mmap the file to address zero * /     pointer = mmap ( 0 , 4096 , PROT \ _READ | PROT \ _WRITE , MAP \ _SHARED | MAP \ _FIXED , fd , 0 ) ; / * note : gcc optimizer does n't know that the return value was null * / / * Let 's dereference that pointer and write to it !
* /     pointer [ 0 ] = 42 ; / * Then we 'll display it , but not using printf     since it refuses to print from null pointers .
* /     write ( 1 , pointer , length ) ; / * Also print the pointer value , just to make sure it is null .
* /     printf ( " Pointer address : \ % d \ n " , ( int ) pointer ) ; / * Now let 's find out if GCC thinks the pointer could possibly be null... * /     if ( pointer = = 0 ) {         printf ( " The pointer is null ! \ n " ) ;     } else {         printf ( " The pointer is not null ! \ n " ) ;     } ; } ; Either way , the pointer is displayed to be zero , but when you run the unoptomized version , it correctly states that the pointer is null , but the optimized version will tell you that it is n't null .
When optimization changes the behavior of a functional program , it is clearly doing the wrong thing .</tokentext>
<sentencetext>Here's a simple test program.
Compare the output when compiled with "gcc -o test test.c" to the output with "gcc -O2 -o test test.c".
I used gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5)(Wow, the "preview" is ruining the formatting of this code.
)#include #include #include #include #include #include #include #include #include #include int main () {
    int fd;
    char *string = "  This text was read from a null pointer!\n";
    int length = strlen(string);
    char *pointer; /* Create a simple file... */
    fd = open("random\_nonexistant\_file", O\_CREAT | O\_RDWR | O\_TRUNC, 0666);
    write(fd, string, length); /* mmap the file to address zero */
    pointer = mmap(0, 4096, PROT\_READ | PROT\_WRITE, MAP\_SHARED | MAP\_FIXED, fd, 0); /* note: gcc optimizer doesn't know that the return value was null */ /* Let's dereference that pointer and write to it!
*/
    pointer[0] = 42; /* Then we'll display it, but not using printf
    since it refuses to print from null pointers.
*/
    write(1, pointer, length); /* Also print the pointer value, just to make sure it is null.
*/
    printf("Pointer address: \%d\n", (int) pointer); /* Now let's find out if GCC thinks the pointer could possibly be null... */
    if (pointer == 0) {
        printf("The pointer is null!\n");
    } else {
        printf("The pointer is not null!\n");
    };};Either way, the pointer is displayed to be zero, but when you run the unoptomized version, it correctly states that the pointer is null, but the optimized version will tell you that it isn't null.
When optimization changes the behavior of a functional program, it is clearly doing the wrong thing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740153</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743043</id>
	<title>Stupid, stupid</title>
	<author>omb</author>
	<datestamp>1247908140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This is all a HUGE nonsense, I sincerely hope that none of you, who think this "undefined" ever write real used code, Goedel's theorem tells you that the compilers cannot know, except in a few tiny, well defined circumstances, what the value of a variable  will be, at run time. That is why compiler optimization is HARD, eg<br><br>As part of the thread has already pointed out, THIS&amp;#160;IS&amp;#160;REALLY&amp;#160;BAD&amp;#160;CODE, full of puns and races, it should never have got past the sub-system maintainer, Morton &amp; Tovolds.<br><br>The moral here is \_\_think\_\_, \_\_write\_\_what\_\_you\_\_mean\_\_, and get sensitive code REVIEWED, by somebody competent.</htmltext>
<tokenext>This is all a HUGE nonsense , I sincerely hope that none of you , who think this " undefined " ever write real used code , Goedel 's theorem tells you that the compilers can not know , except in a few tiny , well defined circumstances , what the value of a variable will be , at run time .
That is why compiler optimization is HARD , egAs part of the thread has already pointed out , THIS   IS   REALLY   BAD   CODE , full of puns and races , it should never have got past the sub-system maintainer , Morton &amp; Tovolds.The moral here is \ _ \ _think \ _ \ _ , \ _ \ _write \ _ \ _what \ _ \ _you \ _ \ _mean \ _ \ _ , and get sensitive code REVIEWED , by somebody competent .</tokentext>
<sentencetext>This is all a HUGE nonsense, I sincerely hope that none of you, who think this "undefined" ever write real used code, Goedel's theorem tells you that the compilers cannot know, except in a few tiny, well defined circumstances, what the value of a variable  will be, at run time.
That is why compiler optimization is HARD, egAs part of the thread has already pointed out, THIS IS REALLY BAD CODE, full of puns and races, it should never have got past the sub-system maintainer, Morton &amp; Tovolds.The moral here is \_\_think\_\_, \_\_write\_\_what\_\_you\_\_mean\_\_, and get sensitive code REVIEWED, by somebody competent.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740153</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743473</id>
	<title>Maybe they should use C99</title>
	<author>Anonymous</author>
	<datestamp>1247911980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A comment on Reddit pointed out something interesting. He speculated that the reason the test was after the assignment is that the programmer was trying to follow the often recommended style of initializing your variables when you declare them. The kernel uses C89, which requires all declarations to be at the top of the function, before any code (other than initializers). Thus, he couldn't test for null before initializing.</p><p>C99 removes the restriction that declarations have to be first in the body. If the kernel were using C99, the programmer could have done his argument sanity checks first, such as the check for the null pointer, and then declared and initialized the variable, AFTER the test.</p></htmltext>
<tokenext>A comment on Reddit pointed out something interesting .
He speculated that the reason the test was after the assignment is that the programmer was trying to follow the often recommended style of initializing your variables when you declare them .
The kernel uses C89 , which requires all declarations to be at the top of the function , before any code ( other than initializers ) .
Thus , he could n't test for null before initializing.C99 removes the restriction that declarations have to be first in the body .
If the kernel were using C99 , the programmer could have done his argument sanity checks first , such as the check for the null pointer , and then declared and initialized the variable , AFTER the test .</tokentext>
<sentencetext>A comment on Reddit pointed out something interesting.
He speculated that the reason the test was after the assignment is that the programmer was trying to follow the often recommended style of initializing your variables when you declare them.
The kernel uses C89, which requires all declarations to be at the top of the function, before any code (other than initializers).
Thus, he couldn't test for null before initializing.C99 removes the restriction that declarations have to be first in the body.
If the kernel were using C99, the programmer could have done his argument sanity checks first, such as the check for the null pointer, and then declared and initialized the variable, AFTER the test.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740207</id>
	<title>Re:Wait, what?</title>
	<author>Anonymous</author>
	<datestamp>1247927160000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>No, dereferencing a NULL pointer results in undefined behaviour. The GCC compiler is generating code which follows the C standard in this case.</p><p>if (tun == null) then the behaviour becomes undefined as soon as the first line is passed.<br>if (tun != null) then the check is not needed.<br>Since "assuming tun is a non-NULL pointer" falls under the remit of "undefined" the compiler is acting reasonably in doing that.</p><p>"Undefined behaviour" includes anything that the program can possibly do, such as setting your printer on fire and emailing death threats to your grandmother. (Although it would be a malicious compiler which generates code that did that deliberately, it would still follow the standard!)</p><p>Therefore the compiler is allowed to assume that the C program guarantees that tun is not NULL at that point. Expecting any specific behaviour, such as the program halting, is outside the C standard. The compiler could optimize out the read to sk if sk is never used, for example, and that would be an entirely reasonable optimization.</p></htmltext>
<tokenext>No , dereferencing a NULL pointer results in undefined behaviour .
The GCC compiler is generating code which follows the C standard in this case.if ( tun = = null ) then the behaviour becomes undefined as soon as the first line is passed.if ( tun ! = null ) then the check is not needed.Since " assuming tun is a non-NULL pointer " falls under the remit of " undefined " the compiler is acting reasonably in doing that .
" Undefined behaviour " includes anything that the program can possibly do , such as setting your printer on fire and emailing death threats to your grandmother .
( Although it would be a malicious compiler which generates code that did that deliberately , it would still follow the standard !
) Therefore the compiler is allowed to assume that the C program guarantees that tun is not NULL at that point .
Expecting any specific behaviour , such as the program halting , is outside the C standard .
The compiler could optimize out the read to sk if sk is never used , for example , and that would be an entirely reasonable optimization .</tokentext>
<sentencetext>No, dereferencing a NULL pointer results in undefined behaviour.
The GCC compiler is generating code which follows the C standard in this case.if (tun == null) then the behaviour becomes undefined as soon as the first line is passed.if (tun != null) then the check is not needed.Since "assuming tun is a non-NULL pointer" falls under the remit of "undefined" the compiler is acting reasonably in doing that.
"Undefined behaviour" includes anything that the program can possibly do, such as setting your printer on fire and emailing death threats to your grandmother.
(Although it would be a malicious compiler which generates code that did that deliberately, it would still follow the standard!
)Therefore the compiler is allowed to assume that the C program guarantees that tun is not NULL at that point.
Expecting any specific behaviour, such as the program halting, is outside the C standard.
The compiler could optimize out the read to sk if sk is never used, for example, and that would be an entirely reasonable optimization.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739915</id>
	<title>Fast! leave the sinking Ship!</title>
	<author>Anonymous</author>
	<datestamp>1247923380000</datestamp>
	<modclass>Funny</modclass>
	<modscore>0</modscore>
	<htmltext><p>Fast! leave the sinking Ship before its too late!</p></htmltext>
<tokenext>Fast !
leave the sinking Ship before its too late !</tokentext>
<sentencetext>Fast!
leave the sinking Ship before its too late!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743427</id>
	<title>Yes it REALLY , it's a compiler bug. (test code)</title>
	<author>omb</author>
	<datestamp>1247911680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Absolute, CORRECT, CLEAR.<br><br>I once had a PhD student who could not understand this, he was very cleaver, but always too agressive, and constantly broke a good optimizing BCPL compiler for the PDP10, since I didnt seem to be able to teach him about regression tests either, even though he did do a lot of good he was, correctly, downgraded to a D.Phil by the external since he couldnt explain himself in the viva.<br><br>Code Review is not useless.</htmltext>
<tokenext>Absolute , CORRECT , CLEAR.I once had a PhD student who could not understand this , he was very cleaver , but always too agressive , and constantly broke a good optimizing BCPL compiler for the PDP10 , since I didnt seem to be able to teach him about regression tests either , even though he did do a lot of good he was , correctly , downgraded to a D.Phil by the external since he couldnt explain himself in the viva.Code Review is not useless .</tokentext>
<sentencetext>Absolute, CORRECT, CLEAR.I once had a PhD student who could not understand this, he was very cleaver, but always too agressive, and constantly broke a good optimizing BCPL compiler for the PDP10, since I didnt seem to be able to teach him about regression tests either, even though he did do a lot of good he was, correctly, downgraded to a D.Phil by the external since he couldnt explain himself in the viva.Code Review is not useless.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742153</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742359</id>
	<title>Re:Serious bug in gcc?</title>
	<author>RightSaidFred99</author>
	<datestamp>1247945100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Yeah....about that...no.</p><p>struct sock *sk = tun-&gt;sk;<nobr> <wbr></nobr>// initialize sk with tun-&gt;sk</p><p>if (!tun)</p><p>return POLLERR;<nobr> <wbr></nobr>// if tun is NULL return error</p><p>There's no null check.  'tun' is literally being checked for 0 or not 0.  I don't know why you're blathering on about nonzero NULL values.</p></htmltext>
<tokenext>Yeah....about that...no.struct sock * sk = tun- &gt; sk ; // initialize sk with tun- &gt; skif ( ! tun ) return POLLERR ; // if tun is NULL return errorThere 's no null check .
'tun ' is literally being checked for 0 or not 0 .
I do n't know why you 're blathering on about nonzero NULL values .</tokentext>
<sentencetext>Yeah....about that...no.struct sock *sk = tun-&gt;sk; // initialize sk with tun-&gt;skif (!tun)return POLLERR; // if tun is NULL return errorThere's no null check.
'tun' is literally being checked for 0 or not 0.
I don't know why you're blathering on about nonzero NULL values.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740413</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741929</id>
	<title>Re:CFLAGS</title>
	<author>systrace</author>
	<datestamp>1247941740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Why do we still allow users to map stuff at page 0?

This compiler optimization is clever and useful, but it assumes that
0 is an invalid address (as it should be and usually is).  The exploit
is taking advantage of the fact that mmap to address 0 is allowed.

To answer my own question:  mmap to 0 might be useful
for emulation sometimes, for example, if emulating an IBM-PC BIOS
in 16-bit mode where physical memory 0 is valid.   Also, it'd break
things to change it now.  We could require a special system
setting before allowing users to do that, but that would also break
things.

However, there's hope for the NULL deref bugs in the kernel.
I've seen patches to fix such problems which seem to be identified
by static analysis tools, so someone's running them.

Very interesting exploit, though.</htmltext>
<tokenext>Why do we still allow users to map stuff at page 0 ?
This compiler optimization is clever and useful , but it assumes that 0 is an invalid address ( as it should be and usually is ) .
The exploit is taking advantage of the fact that mmap to address 0 is allowed .
To answer my own question : mmap to 0 might be useful for emulation sometimes , for example , if emulating an IBM-PC BIOS in 16-bit mode where physical memory 0 is valid .
Also , it 'd break things to change it now .
We could require a special system setting before allowing users to do that , but that would also break things .
However , there 's hope for the NULL deref bugs in the kernel .
I 've seen patches to fix such problems which seem to be identified by static analysis tools , so someone 's running them .
Very interesting exploit , though .</tokentext>
<sentencetext>Why do we still allow users to map stuff at page 0?
This compiler optimization is clever and useful, but it assumes that
0 is an invalid address (as it should be and usually is).
The exploit
is taking advantage of the fact that mmap to address 0 is allowed.
To answer my own question:  mmap to 0 might be useful
for emulation sometimes, for example, if emulating an IBM-PC BIOS
in 16-bit mode where physical memory 0 is valid.
Also, it'd break
things to change it now.
We could require a special system
setting before allowing users to do that, but that would also break
things.
However, there's hope for the NULL deref bugs in the kernel.
I've seen patches to fix such problems which seem to be identified
by static analysis tools, so someone's running them.
Very interesting exploit, though.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740063</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742659</id>
	<title>Re:Linus, you Rookie !!</title>
	<author>Anonymous</author>
	<datestamp>1247947560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>And if I had to venture a guess, this mistake probably came about from one of the commercial contributors. Namely, the one that skyrocketed to the 4th spot in contributions last month (seeing as how well, Red Hat's been at this for a long time now, and while it's not impossible that they committed this flaw to the core, it's far more likely that Intel's newfound interest and throwing muscle @ the linux kernel is probably what caused this).</htmltext>
<tokenext>And if I had to venture a guess , this mistake probably came about from one of the commercial contributors .
Namely , the one that skyrocketed to the 4th spot in contributions last month ( seeing as how well , Red Hat 's been at this for a long time now , and while it 's not impossible that they committed this flaw to the core , it 's far more likely that Intel 's newfound interest and throwing muscle @ the linux kernel is probably what caused this ) .</tokentext>
<sentencetext>And if I had to venture a guess, this mistake probably came about from one of the commercial contributors.
Namely, the one that skyrocketed to the 4th spot in contributions last month (seeing as how well, Red Hat's been at this for a long time now, and while it's not impossible that they committed this flaw to the core, it's far more likely that Intel's newfound interest and throwing muscle @ the linux kernel is probably what caused this).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740127</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740063</id>
	<title>CFLAGS</title>
	<author>Anonymous</author>
	<datestamp>1247925480000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>CFLAGS+= -fno-delete-null-pointer-checks</p><p>Job done (should work with Gentoo, buggered if I know how to do this in other distros, DYOR), even with -O2/-O3. This is an optimisation/code conflict. The code itself is perfectly valid, so if your CFLAGS are -O -pipe you have nothing to worry about. GCC's info pages show what is enabled at various optimisation levels. -fdelete-null-pointer-checks is enabled at -O2. Of course, this only applies when you compile your own kernel. If vendors are supplying kernels compiled with -O2 without checking what it does to the code then it is obvious who is to blame.</p></htmltext>
<tokenext>CFLAGS + = -fno-delete-null-pointer-checksJob done ( should work with Gentoo , buggered if I know how to do this in other distros , DYOR ) , even with -O2/-O3 .
This is an optimisation/code conflict .
The code itself is perfectly valid , so if your CFLAGS are -O -pipe you have nothing to worry about .
GCC 's info pages show what is enabled at various optimisation levels .
-fdelete-null-pointer-checks is enabled at -O2 .
Of course , this only applies when you compile your own kernel .
If vendors are supplying kernels compiled with -O2 without checking what it does to the code then it is obvious who is to blame .</tokentext>
<sentencetext>CFLAGS+= -fno-delete-null-pointer-checksJob done (should work with Gentoo, buggered if I know how to do this in other distros, DYOR), even with -O2/-O3.
This is an optimisation/code conflict.
The code itself is perfectly valid, so if your CFLAGS are -O -pipe you have nothing to worry about.
GCC's info pages show what is enabled at various optimisation levels.
-fdelete-null-pointer-checks is enabled at -O2.
Of course, this only applies when you compile your own kernel.
If vendors are supplying kernels compiled with -O2 without checking what it does to the code then it is obvious who is to blame.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742799</id>
	<title>Re:Serious bug in gcc?</title>
	<author>Anonymous</author>
	<datestamp>1247948820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>GCC makes use of the fact that in the C language any pointer that was dereferenced can't be NULL (this is made explicit in the standard).</p></div><p>At this point you could add vast amounts of credibility to your post by providing a reference to the appropriate part of the C spec. If you are so sure the standard says this then presumably you know roughly where so it would be a quick job for you too. This would be so helpful to those of us trying to make up our own minds. I now have to go away and re-read the spec. to find out if this assertion is true.</p></div>
	</htmltext>
<tokenext>GCC makes use of the fact that in the C language any pointer that was dereferenced ca n't be NULL ( this is made explicit in the standard ) .At this point you could add vast amounts of credibility to your post by providing a reference to the appropriate part of the C spec .
If you are so sure the standard says this then presumably you know roughly where so it would be a quick job for you too .
This would be so helpful to those of us trying to make up our own minds .
I now have to go away and re-read the spec .
to find out if this assertion is true .</tokentext>
<sentencetext>GCC makes use of the fact that in the C language any pointer that was dereferenced can't be NULL (this is made explicit in the standard).At this point you could add vast amounts of credibility to your post by providing a reference to the appropriate part of the C spec.
If you are so sure the standard says this then presumably you know roughly where so it would be a quick job for you too.
This would be so helpful to those of us trying to make up our own minds.
I now have to go away and re-read the spec.
to find out if this assertion is true.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740141</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28748299</id>
	<title>Re:Serious bug in gcc?</title>
	<author>DavidTC</author>
	<datestamp>1248025140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Erm, if you think that b-&gt;c isn't accessing the memory of b, you need a C refresher course.</p><p>
Assigning b to something would be fine if b was NULL. Assigning b-&gt;c requires reading b to find out where c is pointing. It does not require reading c, and hence c can be NULL, but it requires reading b, which cannot be NULL.</p></htmltext>
<tokenext>Erm , if you think that b- &gt; c is n't accessing the memory of b , you need a C refresher course .
Assigning b to something would be fine if b was NULL .
Assigning b- &gt; c requires reading b to find out where c is pointing .
It does not require reading c , and hence c can be NULL , but it requires reading b , which can not be NULL .</tokentext>
<sentencetext>Erm, if you think that b-&gt;c isn't accessing the memory of b, you need a C refresher course.
Assigning b to something would be fine if b was NULL.
Assigning b-&gt;c requires reading b to find out where c is pointing.
It does not require reading c, and hence c can be NULL, but it requires reading b, which cannot be NULL.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741691</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740413</id>
	<title>Re:Serious bug in gcc?</title>
	<author>TheSunborn</author>
	<datestamp>1247929080000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>This sound more like a gcc/embeded os bug. There is no requirement in c/c++ that the null pointer is (int)0. That is: It don't have to be all 0 bits.<br>It just need to be distinct from any valid pointer, so if you run on a platform where you use memory address 0(Valid, but still wierd), you need<br>to config gcc(If possible, I don't know if gcc supports this) to use an other bit pattern as null pointer(say 0xeffff), and then you need to configure your embeded os, to never<br>return a memory address/buffer that contain the address you have used as null pointer.</p></htmltext>
<tokenext>This sound more like a gcc/embeded os bug .
There is no requirement in c/c + + that the null pointer is ( int ) 0 .
That is : It do n't have to be all 0 bits.It just need to be distinct from any valid pointer , so if you run on a platform where you use memory address 0 ( Valid , but still wierd ) , you needto config gcc ( If possible , I do n't know if gcc supports this ) to use an other bit pattern as null pointer ( say 0xeffff ) , and then you need to configure your embeded os , to neverreturn a memory address/buffer that contain the address you have used as null pointer .</tokentext>
<sentencetext>This sound more like a gcc/embeded os bug.
There is no requirement in c/c++ that the null pointer is (int)0.
That is: It don't have to be all 0 bits.It just need to be distinct from any valid pointer, so if you run on a platform where you use memory address 0(Valid, but still wierd), you needto config gcc(If possible, I don't know if gcc supports this) to use an other bit pattern as null pointer(say 0xeffff), and then you need to configure your embeded os, to neverreturn a memory address/buffer that contain the address you have used as null pointer.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740141</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741793</id>
	<title>Re:CFLAGS</title>
	<author>colsandurz45</author>
	<datestamp>1247940780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>From the man page:

       -fdelete-null-pointer-checks
           Use global dataflow analysis to identify and eliminate useless
           checks for null pointers.  The compiler assumes that dereferencing
           a null pointer would have halted the program.  If a pointer is
           checked after it has already been dereferenced, it cannot be null.

           In some environments, this assumption is not true, and programs can
           safely dereference null pointers.  Use
           -fno-delete-null-pointer-checks to disable this optimization for
           programs which depend on that behavior.

           Enabled at levels -O2, -O3, -Os.

       -fno-delete-null-pointer-checks to disable this optimization for
           programs which depend on that behavior.

           Enabled at levels -O2, -O3, -Os.</htmltext>
<tokenext>From the man page : -fdelete-null-pointer-checks Use global dataflow analysis to identify and eliminate useless checks for null pointers .
The compiler assumes that dereferencing a null pointer would have halted the program .
If a pointer is checked after it has already been dereferenced , it can not be null .
In some environments , this assumption is not true , and programs can safely dereference null pointers .
Use -fno-delete-null-pointer-checks to disable this optimization for programs which depend on that behavior .
Enabled at levels -O2 , -O3 , -Os .
-fno-delete-null-pointer-checks to disable this optimization for programs which depend on that behavior .
Enabled at levels -O2 , -O3 , -Os .</tokentext>
<sentencetext>From the man page:

       -fdelete-null-pointer-checks
           Use global dataflow analysis to identify and eliminate useless
           checks for null pointers.
The compiler assumes that dereferencing
           a null pointer would have halted the program.
If a pointer is
           checked after it has already been dereferenced, it cannot be null.
In some environments, this assumption is not true, and programs can
           safely dereference null pointers.
Use
           -fno-delete-null-pointer-checks to disable this optimization for
           programs which depend on that behavior.
Enabled at levels -O2, -O3, -Os.
-fno-delete-null-pointer-checks to disable this optimization for
           programs which depend on that behavior.
Enabled at levels -O2, -O3, -Os.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740063</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740617</id>
	<title>Re:Serious bug in gcc?</title>
	<author>Anonymous</author>
	<datestamp>1247930760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><blockquote><div><p>Linux fixes this by using the aforementioned new compiler option to not have the NULL pointer check optimized away.</p></div></blockquote><p>Really? I thought the fix was <a href="http://kerneltrap.org/mailarchive/git-commits-head/2009/7/7/6148853" title="kerneltrap.org" rel="nofollow">http://kerneltrap.org/mailarchive/git-commits-head/2009/7/7/6148853</a> [kerneltrap.org] . Can you show me where this is reverted in favor of changing the compiler options?</p></div>
	</htmltext>
<tokenext>Linux fixes this by using the aforementioned new compiler option to not have the NULL pointer check optimized away.Really ?
I thought the fix was http : //kerneltrap.org/mailarchive/git-commits-head/2009/7/7/6148853 [ kerneltrap.org ] .
Can you show me where this is reverted in favor of changing the compiler options ?</tokentext>
<sentencetext>Linux fixes this by using the aforementioned new compiler option to not have the NULL pointer check optimized away.Really?
I thought the fix was http://kerneltrap.org/mailarchive/git-commits-head/2009/7/7/6148853 [kerneltrap.org] .
Can you show me where this is reverted in favor of changing the compiler options?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740141</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739981</id>
	<title>Re:Double standards</title>
	<author>Anonymous</author>
	<datestamp>1247924400000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>If this had been Windows we'd find out 9 months later after the guy who discovered it informed Microsoft, they stick their fingers up their butt for 3 months.  Microsoft would then spend 3 months finding that the code they used to fix the problem (which was copied from a dll they wrote in 2005) causes problems in newer versions of Excel because it uses null pointers to calculate file bloat or something.  Then they threaten him with lawsuits for a few months if he releases the information.  In a rush to release a fix MS uses a newer bit of code that breaks all versions of Excel because they really dont need another reason for people not to upgrade.</p><p>The end result of which is that MS releases a fix mere days after the flaw is "announced".</p><p>The Excel bug goes unfixed for 4 years because its a low priority and nobody has found a way to exploit it <b>yet</b>.</p></htmltext>
<tokenext>If this had been Windows we 'd find out 9 months later after the guy who discovered it informed Microsoft , they stick their fingers up their butt for 3 months .
Microsoft would then spend 3 months finding that the code they used to fix the problem ( which was copied from a dll they wrote in 2005 ) causes problems in newer versions of Excel because it uses null pointers to calculate file bloat or something .
Then they threaten him with lawsuits for a few months if he releases the information .
In a rush to release a fix MS uses a newer bit of code that breaks all versions of Excel because they really dont need another reason for people not to upgrade.The end result of which is that MS releases a fix mere days after the flaw is " announced " .The Excel bug goes unfixed for 4 years because its a low priority and nobody has found a way to exploit it yet .</tokentext>
<sentencetext>If this had been Windows we'd find out 9 months later after the guy who discovered it informed Microsoft, they stick their fingers up their butt for 3 months.
Microsoft would then spend 3 months finding that the code they used to fix the problem (which was copied from a dll they wrote in 2005) causes problems in newer versions of Excel because it uses null pointers to calculate file bloat or something.
Then they threaten him with lawsuits for a few months if he releases the information.
In a rush to release a fix MS uses a newer bit of code that breaks all versions of Excel because they really dont need another reason for people not to upgrade.The end result of which is that MS releases a fix mere days after the flaw is "announced".The Excel bug goes unfixed for 4 years because its a low priority and nobody has found a way to exploit it yet.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739929</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740123</id>
	<title>what the...?!</title>
	<author>Anonymous</author>
	<datestamp>1247926200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Why the crap doesn't "tun-&gt;sk" panic the kernel? They had it coming if the userland can tamper with the kernel's mapping of page 0.</p></htmltext>
<tokenext>Why the crap does n't " tun- &gt; sk " panic the kernel ?
They had it coming if the userland can tamper with the kernel 's mapping of page 0 .</tokentext>
<sentencetext>Why the crap doesn't "tun-&gt;sk" panic the kernel?
They had it coming if the userland can tamper with the kernel's mapping of page 0.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28755629</id>
	<title>Re:What's kept me from bothering with Linux.</title>
	<author>Tweenk</author>
	<datestamp>1248101580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Comon guys, someone make a utility that makes compiling and installing a kernel impossible to screw up.</p></div><p>Already exists.<br>make-kpkg --initrd --append-to-version=-custom kernel\_image kernel\_headers<br>dpkg -i linux-*</p><p>Not sure about RPM-based distros.</p></div>
	</htmltext>
<tokenext>Comon guys , someone make a utility that makes compiling and installing a kernel impossible to screw up.Already exists.make-kpkg --initrd --append-to-version = -custom kernel \ _image kernel \ _headersdpkg -i linux- * Not sure about RPM-based distros .</tokentext>
<sentencetext>Comon guys, someone make a utility that makes compiling and installing a kernel impossible to screw up.Already exists.make-kpkg --initrd --append-to-version=-custom kernel\_image kernel\_headersdpkg -i linux-*Not sure about RPM-based distros.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742051</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28746455</id>
	<title>Re:Wait, what?</title>
	<author>Anonymous</author>
	<datestamp>1247997840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Except the compiler would be wrong, in the case of zero mapped pages...</p></htmltext>
<tokenext>Except the compiler would be wrong , in the case of zero mapped pages.. .</tokentext>
<sentencetext>Except the compiler would be wrong, in the case of zero mapped pages...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740137</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741529</id>
	<title>Re:I always disable those</title>
	<author>godrik</author>
	<datestamp>1247938620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>AppArmor is a security module that allows to associate to each process (binary perhaps, I do not know exactly) a exact list of files it can access.
The point is that even if apache is running as root and is corrupted, it can not read or modify files from<nobr> <wbr></nobr>/etc or<nobr> <wbr></nobr>/usr...</htmltext>
<tokenext>AppArmor is a security module that allows to associate to each process ( binary perhaps , I do not know exactly ) a exact list of files it can access .
The point is that even if apache is running as root and is corrupted , it can not read or modify files from /etc or /usr.. .</tokentext>
<sentencetext>AppArmor is a security module that allows to associate to each process (binary perhaps, I do not know exactly) a exact list of files it can access.
The point is that even if apache is running as root and is corrupted, it can not read or modify files from /etc or /usr...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739985</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061</id>
	<title>Wait, what?</title>
	<author>Anonymous</author>
	<datestamp>1247925480000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext>This code looks right?<blockquote><div><p> <tt>struct sock *sk = tun-&gt;sk;<nobr> <wbr></nobr>// initialize sk with tun-&gt;sk<br>...<br>if (!tun)<br>  return POLLERR;<nobr> <wbr></nobr>// if tun is NULL return error</tt></p></div> </blockquote><p>So, he's dereferencing tun, and <i>then</i> checking if tun was NULL?  Looks like the compiler is performing an incorrect optimisation if it's removing the test, but it's still horribly bad style.  This ought to be crashing at the sk = tun-&gt;sk line, because the structure is smaller than a page, and page 0 is mapped no-access (I assume Linux does this; it's been standard practice in most operating systems for a couple of decades to protect against NULL-pointer dereferencing).  Technically, however, the C standard allows tun-&gt;sk to be a valid address, so removing the test is a semantically-invalid optimisation.  In practice, it's safe for any structure smaller than a page, because the code should crash before reaching the test.  </p><p>
So, we have bad code in Linux and bad code in GCC, combining to make this a true GNU/Linux vulnerability.</p></div>
	</htmltext>
<tokenext>This code looks right ?
struct sock * sk = tun- &gt; sk ; // initialize sk with tun- &gt; sk...if ( ! tun ) return POLLERR ; // if tun is NULL return error So , he 's dereferencing tun , and then checking if tun was NULL ?
Looks like the compiler is performing an incorrect optimisation if it 's removing the test , but it 's still horribly bad style .
This ought to be crashing at the sk = tun- &gt; sk line , because the structure is smaller than a page , and page 0 is mapped no-access ( I assume Linux does this ; it 's been standard practice in most operating systems for a couple of decades to protect against NULL-pointer dereferencing ) .
Technically , however , the C standard allows tun- &gt; sk to be a valid address , so removing the test is a semantically-invalid optimisation .
In practice , it 's safe for any structure smaller than a page , because the code should crash before reaching the test .
So , we have bad code in Linux and bad code in GCC , combining to make this a true GNU/Linux vulnerability .</tokentext>
<sentencetext>This code looks right?
struct sock *sk = tun-&gt;sk; // initialize sk with tun-&gt;sk...if (!tun)  return POLLERR; // if tun is NULL return error So, he's dereferencing tun, and then checking if tun was NULL?
Looks like the compiler is performing an incorrect optimisation if it's removing the test, but it's still horribly bad style.
This ought to be crashing at the sk = tun-&gt;sk line, because the structure is smaller than a page, and page 0 is mapped no-access (I assume Linux does this; it's been standard practice in most operating systems for a couple of decades to protect against NULL-pointer dereferencing).
Technically, however, the C standard allows tun-&gt;sk to be a valid address, so removing the test is a semantically-invalid optimisation.
In practice, it's safe for any structure smaller than a page, because the code should crash before reaching the test.
So, we have bad code in Linux and bad code in GCC, combining to make this a true GNU/Linux vulnerability.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740649</id>
	<title>Can enyone explain this?</title>
	<author>bperkins</author>
	<datestamp>1247930940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>&lt;em&gt; This will cause the kernel to try to read/write data from 0x00000000, which the attacker can map to userland &lt;/em&gt;<br><br>This was somewhat surprising to me.  Digging around a bit, it looks like it has something to do with an seLinux handler.<br><br>Can anyone elaborate on this?</htmltext>
<tokenext>This will cause the kernel to try to read/write data from 0x00000000 , which the attacker can map to userland This was somewhat surprising to me .
Digging around a bit , it looks like it has something to do with an seLinux handler.Can anyone elaborate on this ?</tokentext>
<sentencetext> This will cause the kernel to try to read/write data from 0x00000000, which the attacker can map to userland This was somewhat surprising to me.
Digging around a bit, it looks like it has something to do with an seLinux handler.Can anyone elaborate on this?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739977</id>
	<title>Re:Double standards</title>
	<author>Anonymous</author>
	<datestamp>1247924340000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>Thats because with Windows, no one would be able to marvel at how un-obvious the flaw is. According to The Register, the kernel actually has gaurds in place against just this type of valnerability, but the complier optimized them out during compiling. IMHO this makes this flaw a very good case study, even with security in place, you cannot really trust the compiler. (actually, this flaw apparently only occurs if security is in place... or if you use PulseAudio (in which case, you deserve it!)).</p></htmltext>
<tokenext>Thats because with Windows , no one would be able to marvel at how un-obvious the flaw is .
According to The Register , the kernel actually has gaurds in place against just this type of valnerability , but the complier optimized them out during compiling .
IMHO this makes this flaw a very good case study , even with security in place , you can not really trust the compiler .
( actually , this flaw apparently only occurs if security is in place... or if you use PulseAudio ( in which case , you deserve it !
) ) .</tokentext>
<sentencetext>Thats because with Windows, no one would be able to marvel at how un-obvious the flaw is.
According to The Register, the kernel actually has gaurds in place against just this type of valnerability, but the complier optimized them out during compiling.
IMHO this makes this flaw a very good case study, even with security in place, you cannot really trust the compiler.
(actually, this flaw apparently only occurs if security is in place... or if you use PulseAudio (in which case, you deserve it!
)).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739929</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741723</id>
	<title>Re:Serious bug in gcc?</title>
	<author>Anonymous</author>
	<datestamp>1247940180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"any pointer that was dereferenced can't be NULL"</p><p>It's not being dereferenced.</p></htmltext>
<tokenext>" any pointer that was dereferenced ca n't be NULL " It 's not being dereferenced .</tokentext>
<sentencetext>"any pointer that was dereferenced can't be NULL"It's not being dereferenced.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740141</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741157</id>
	<title>Interesting</title>
	<author>improfane</author>
	<datestamp>1247935380000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext><p>Guys, I'm trying to decide what to post:</p><p>[ ] Downplay how serious flaw is<br>[ ] Compare to Window's track record<br>[x] Make a meta-reference to Slashdot psychology<br>[ ] Post work-around that doesn't fix problem<br>[ ] Say that flaw is a feature<br>[ ] bash Windows<br>
&nbsp; [ ] Claim that not all Windows software is bad<br>[ ] Claim that the more popular gets, Linux will be targeted more<br>[ ] Pretend I understand the problem<nobr> <wbr></nobr>...or we could RFA</p></htmltext>
<tokenext>Guys , I 'm trying to decide what to post : [ ] Downplay how serious flaw is [ ] Compare to Window 's track record [ x ] Make a meta-reference to Slashdot psychology [ ] Post work-around that does n't fix problem [ ] Say that flaw is a feature [ ] bash Windows   [ ] Claim that not all Windows software is bad [ ] Claim that the more popular gets , Linux will be targeted more [ ] Pretend I understand the problem ...or we could RFA</tokentext>
<sentencetext>Guys, I'm trying to decide what to post:[ ] Downplay how serious flaw is[ ] Compare to Window's track record[x] Make a meta-reference to Slashdot psychology[ ] Post work-around that doesn't fix problem[ ] Say that flaw is a feature[ ] bash Windows
  [ ] Claim that not all Windows software is bad[ ] Claim that the more popular gets, Linux will be targeted more[ ] Pretend I understand the problem ...or we could RFA</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739911</id>
	<title>Linux More Secure than Windows?</title>
	<author>Anonymous</author>
	<datestamp>1247923260000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>You betcha!</p></htmltext>
<tokenext>You betcha !</tokentext>
<sentencetext>You betcha!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742051</id>
	<title>What's kept me from bothering with Linux.</title>
	<author>dicobalt</author>
	<datestamp>1247942880000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext><p>Everytime I try to use Linux I always end up needing to compile the kernel because I want some special feature or software package that requires it.  Software that doesn't ship with any distro as a prepackaged<nobr> <wbr></nobr>... package.  Anyways, I hate the kernel compile procedures, what a pain.  I really wish there was a better tool than menuconfig/xconfig and the ensuing make and install commands.</p><p>For some unexplained reason I always get an obscure weird error.  I do know C/C++ but I am not a programmer (especially not a kernel programmer on Linux) so I really don't want to spend days figuring it out.  I just want to use it.  I am truly amazed it's been 13 years (the first time I compiled a Linux kernel successfully) and there is *STILL* no nice program to manage kernel compiles and translate common errors into plain english or even spanish(which I don't know lol).</p><p>Then an exploit comes out or a necessary kernel upgrade happens and I have to go through it all again.  Ugh.  Comon guys, someone make a utility that makes compiling and installing a kernel impossible to screw up.  Easy even when it's giving bizzare errors.  Because the damn thing never does what it's supposed to do!  Argh!</p><p>For that matter this wonderful tool should be able to handle compiling any source for nearly any software.  You shouldn't need a stinkin RPM or APT package which I can never seem to find the right flavor of even when they are available.  Every distro needs to have the same easy to use tool that compiles directly from source and can deal with common errors itself.</p><p>13 years, and I'm still waiting.</p></htmltext>
<tokenext>Everytime I try to use Linux I always end up needing to compile the kernel because I want some special feature or software package that requires it .
Software that does n't ship with any distro as a prepackaged ... package. Anyways , I hate the kernel compile procedures , what a pain .
I really wish there was a better tool than menuconfig/xconfig and the ensuing make and install commands.For some unexplained reason I always get an obscure weird error .
I do know C/C + + but I am not a programmer ( especially not a kernel programmer on Linux ) so I really do n't want to spend days figuring it out .
I just want to use it .
I am truly amazed it 's been 13 years ( the first time I compiled a Linux kernel successfully ) and there is * STILL * no nice program to manage kernel compiles and translate common errors into plain english or even spanish ( which I do n't know lol ) .Then an exploit comes out or a necessary kernel upgrade happens and I have to go through it all again .
Ugh. Comon guys , someone make a utility that makes compiling and installing a kernel impossible to screw up .
Easy even when it 's giving bizzare errors .
Because the damn thing never does what it 's supposed to do !
Argh ! For that matter this wonderful tool should be able to handle compiling any source for nearly any software .
You should n't need a stinkin RPM or APT package which I can never seem to find the right flavor of even when they are available .
Every distro needs to have the same easy to use tool that compiles directly from source and can deal with common errors itself.13 years , and I 'm still waiting .</tokentext>
<sentencetext>Everytime I try to use Linux I always end up needing to compile the kernel because I want some special feature or software package that requires it.
Software that doesn't ship with any distro as a prepackaged ... package.  Anyways, I hate the kernel compile procedures, what a pain.
I really wish there was a better tool than menuconfig/xconfig and the ensuing make and install commands.For some unexplained reason I always get an obscure weird error.
I do know C/C++ but I am not a programmer (especially not a kernel programmer on Linux) so I really don't want to spend days figuring it out.
I just want to use it.
I am truly amazed it's been 13 years (the first time I compiled a Linux kernel successfully) and there is *STILL* no nice program to manage kernel compiles and translate common errors into plain english or even spanish(which I don't know lol).Then an exploit comes out or a necessary kernel upgrade happens and I have to go through it all again.
Ugh.  Comon guys, someone make a utility that makes compiling and installing a kernel impossible to screw up.
Easy even when it's giving bizzare errors.
Because the damn thing never does what it's supposed to do!
Argh!For that matter this wonderful tool should be able to handle compiling any source for nearly any software.
You shouldn't need a stinkin RPM or APT package which I can never seem to find the right flavor of even when they are available.
Every distro needs to have the same easy to use tool that compiles directly from source and can deal with common errors itself.13 years, and I'm still waiting.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28746647</id>
	<title>Re:Maybe they should use C99</title>
	<author>True Grit</author>
	<datestamp>1248002280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Thus, he couldn't test for null before initializing.</p></div><p>Of course he could.  'recommended style' != 'required rule'</p><p>In fact, in the very next function that follows the function with the bug in tun.c, there is an uninitialized variable being declared, and then initialized later, *after* a sanity check.  In hindsight, this should have been done here too.</p><p>I'm guessing the author probably just made an honest mistake of looking at the code above:</p><blockquote><div><p> <tt>struct tun\_struct *tun = \_\_tun\_get(tfile);</tt></p></div> </blockquote><p>and thinking that the \_\_tun\_get function, which initializes the tun pointer, wouldn't return a NULL.  We now know it obviously can, so perhaps he simply forgot or misremembered that.</p><p><div class="quote"><p>If the kernel were using C99, the programmer could have done his argument sanity checks first</p></div><p>Programmers still make mistakes when using C99 too.  After all, this *is* pointer-heavy C we're talking about here.<nobr> <wbr></nobr>:)</p></div>
	</htmltext>
<tokenext>Thus , he could n't test for null before initializing.Of course he could .
'recommended style ' ! = 'required rule'In fact , in the very next function that follows the function with the bug in tun.c , there is an uninitialized variable being declared , and then initialized later , * after * a sanity check .
In hindsight , this should have been done here too.I 'm guessing the author probably just made an honest mistake of looking at the code above : struct tun \ _struct * tun = \ _ \ _tun \ _get ( tfile ) ; and thinking that the \ _ \ _tun \ _get function , which initializes the tun pointer , would n't return a NULL .
We now know it obviously can , so perhaps he simply forgot or misremembered that.If the kernel were using C99 , the programmer could have done his argument sanity checks firstProgrammers still make mistakes when using C99 too .
After all , this * is * pointer-heavy C we 're talking about here .
: )</tokentext>
<sentencetext>Thus, he couldn't test for null before initializing.Of course he could.
'recommended style' != 'required rule'In fact, in the very next function that follows the function with the bug in tun.c, there is an uninitialized variable being declared, and then initialized later, *after* a sanity check.
In hindsight, this should have been done here too.I'm guessing the author probably just made an honest mistake of looking at the code above: struct tun\_struct *tun = \_\_tun\_get(tfile); and thinking that the \_\_tun\_get function, which initializes the tun pointer, wouldn't return a NULL.
We now know it obviously can, so perhaps he simply forgot or misremembered that.If the kernel were using C99, the programmer could have done his argument sanity checks firstProgrammers still make mistakes when using C99 too.
After all, this *is* pointer-heavy C we're talking about here.
:)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743473</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741625
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740137
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742541
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741691
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740087
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740019
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740597
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739981
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739929
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741431
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739985
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28755629
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742051
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742321
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741691
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740087
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740019
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741529
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739985
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740207
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743895
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740413
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740141
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740019
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28748299
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741691
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740087
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740019
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740713
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740063
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740451
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739977
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739929
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740617
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740141
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740019
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743559
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742051
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741929
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740063
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28751327
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742365
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740137
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742411
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739999
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742799
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740141
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740019
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28746737
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742221
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739977
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739929
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742659
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740127
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739911
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739967
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739929
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741251
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739985
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743427
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742153
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740153
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740289
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740063
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742931
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740137
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740637
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739977
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739929
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741275
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28746647
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743473
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28744017
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743473
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28746455
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740137
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741723
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740141
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740019
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743043
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740153
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740385
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28750265
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742507
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739977
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739929
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742359
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740413
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740141
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740019
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_18_0136224_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741793
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740063
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_18_0136224.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740123
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_18_0136224.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741497
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_18_0136224.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740019
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740087
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741691
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742321
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28748299
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742541
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740141
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741723
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742799
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740617
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740413
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743895
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742359
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_18_0136224.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741425
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_18_0136224.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739911
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740127
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742659
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_18_0136224.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740061
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740385
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740207
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740137
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742931
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742365
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28751327
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28746455
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741625
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741275
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740153
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743043
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742153
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743427
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_18_0136224.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740063
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740289
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741929
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741793
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740713
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_18_0136224.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739985
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741529
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741251
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28741431
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_18_0136224.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739929
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739981
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740597
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739967
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739977
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742221
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28746737
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742507
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28750265
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740637
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28740451
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_18_0136224.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28739999
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742411
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_18_0136224.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743473
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28744017
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28746647
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_18_0136224.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28742051
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28743559
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_18_0136224.28755629
</commentlist>
</conversation>
