The link to the lwn.net article explains that using mmap the naughty application mapped a page to virtual 0, which was then available in kernel mode in that process, and all they'd need to do is put their own "socket" structure at 0 + offsetof(struct tun_struct, sk). On 25 November 2015 at 10:43, Brantley Coile wrote: > Just curious, will Linux not panic when the kernel deterrences a nil > pointer? > > Sent from my iPad > > On Nov 25, 2015, at 5:27 AM, Alexandru Gheorghe > wrote: > > On 11/23/2015 01:20 PM, Vasudev Kamath wrote: > > Ramakrishnan Muthukrishnan writes: > > > Had been reading the SOSP paper: > > and this blog post that proposes a simpler C: > > I started reading the paper and its interesting. I didn't knew till date > how optimizations really worked and why they were considered harmful. > > > They can be quite harmful, the dereference example of *tun->sk* is a > popular example that dates from 2009 regarding the Linux Kernel being > exploited by Spender (Brad Spengler): https://lwn.net/Articles/342330/ > > "a NULL pointer was dereferenced before being checked, the check was > optimized out by the compiler, and the code used the NULL pointer in a way > which allowed the attacker to take over the system" > > > Funny because Spengler did try many times to introduce better security in > the Linux Kernel (see his set of patches in collaboration with the PaX > Team: GRSEC) but was refused many times by the community and Linus in > particular due to performance penalties (among other "opinions"). Which > again opens the question where exactly is the undefined behavior problem? > Resides on the programmer or on the compiler (and its programmers)? And how > do you deal with the performance side? Because clearly, if you introduce > more security then you will start having penalties on it; I guess the > question is how much are you willing to let go in preference of more > security and stable systems? > > It's a very interesting paper, I only read 7 pages but will soon finish it > and go ahead with the references (probably it links the example I wrote in > the beginning of this e-mail). > > Thanks for sharing. > > -- > ; Alexandru Gheorghe > ; > ; aGlobal > ; > >