[grsec] Kernel Hangs: Highmem and GRSECURITY

[Syed Ahemed]

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