[grsec] Kernel Hangs: Highmem and GRSECURITY

[Syed Ahemed]

Kernel version i am addressing the problem is
2.4.28 and the grsecurity patch is 2.1.0




On 9/15/06, Syed Ahemed <kingkhan at gmail.com> wrote:
> Hello ,
> I wonder if you remeber this problem i was facing a couple of days
> back about the kernel hang i noticed.
> As per your suggestion i have upgraded to the latest 2.1.9 grsecurity
> patch and i dont any longer see the issue.
> But for sake of my learning n curiosity , I tried looking at the
> difference between 2.1.0 and 2.1.9 patch .
>
> I noticed the following based on my month long analysis.
> Since it was evident from /proc/meminfo i was running out of either
> physical or virtual memory during the hang i tried to dig into the
> source code and found the following code , which after commenting out
> i no longer see the hang .This is what is exactly done in 2.1.9
> patch.My question to the community is related to this code.
> Can you throw me some light or pointers where i can find the changelog
>  or the reason why this change was made .
>
> In the following excerpts of the code the IFDEFINED PAXSEGMEXEC code
> was removed and the kernel hang is no longer seen.In the 2.1.9 patch
> this code is not added .From my understanding if vm_flags & VM_MIRROR
> results to 0 only then the "if" statements are executed , else it is
> skipped.My analysis shows it is skipped and so the kernel hangs
> subsequently.
>
> Why was this code added and why is it removed
>
>
> /usr/src/linux-2.4/mm/mmap.c
>
>    /* Check against address space limit. */
> #if defined(CONFIG_GRKERNSEC_PAX_SEGMEXEC) ||
> defined(CONFIG_GRKERNSEC_PAX_RANDEXEC)
>    if (!(vm_flags & VM_MIRROR)) {
> #endif
>    gr_learn_resource(current, RLIMIT_AS, (mm->total_vm << PAGE_SHIFT)
> + len, 1);
>    if ((mm->total_vm << PAGE_SHIFT) + len
>        > current->rlim[RLIMIT_AS].rlim_cur)
>        return -ENOMEM;
>
>
>
>
> Regards
> King khan
>
>
>
> On 9/9/06, Syed Ahemed <kingkhan at gmail.com> wrote:
> > Cool ,Thanks a lot .
> > In a hurry to get my 15 minutes of fame ,I missed the apparent difference:-)
> > Will be extra careful the next time around.Regret wasting your time sir.
> >
> > On 9/9/06, pageexec at freemail.hu <pageexec at freemail.hu> wrote:
> > > On 9 Sep 2006 at 6:03, Syed Ahemed wrote:
> > >
> > > > Hello ,
> > > > In the excerpts 2.1.9 grsecurity patch , kmem_cache_free is called
> > > > when kmem_cache_alloc fails (returns 0)   .Isn't this a case of
> > > > dereferencing a Null pointer.
> > >
> > > notice that what we free is 'mpnt', not 'mpnt_m', that is, we just
> > > prevent leaking a previously allocated item, i don't see where the
> > > NULL ptr is dereferenced.
> > >
> > > > The kernel code without the Patch  otherwise is filled with calls to
> > > > kmem_cache_alloc that just returns -ENOMEM in case of failure.
> > > >
> > > > Could you please explain the reason ?
> > > >
> > > > +#ifdef CONFIG_GRKERNSEC_PAX_SEGMEXEC
> > > > +   if ((current->mm->pax_flags & MF_PAX_SEGMEXEC) && (VM_STACK_FLAGS
> > > > & VM_MAYEXEC)) {
> > > > +       mpnt_m = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
> > > > +       if (!mpnt_m) {
> > > > +           kmem_cache_free(vm_area_cachep, mpnt);
> > > > +           return -ENOMEM;
> > > > +       }
> > > > +   }
> > > > +#endif
> > > > +
> > >
> > >
> > >
> >
> >
> > --
> > Azhar khan
> >
> > I'm afraid that I've seen too many people fix bugs by looking at
> > debugger output, and that almost inevitably leads to fixing the
> > symptoms rather than the underlying problems.
> >
> > --Linus
> >
>
>
> --
> Azhar khan
>
> I'm afraid that I've seen too many people fix bugs by looking at
> debugger output, and that almost inevitably leads to fixing the
> symptoms rather than the underlying problems.
>
> --Linus
>


-- 
Azhar khan

I'm afraid that I've seen too many people fix bugs by looking at
debugger output, and that almost inevitably leads to fixing the
symptoms rather than the underlying problems.
	
--Linus