Re: Kernel Panic

["PaX Team" <pageexec@freemail.hu>]

On 6 Dec 2016 at 23:39, Jason A. Donenfeld wrote:

[added spender to CC as it's his feature in grsec]

> Hey PaXTeam,
> 
> I tracked down Samuel's bug to this line in crypto/scatterwalk.c:
>         if (sg_page(sg) == virt_to_page(realbuf) &&
> 
> virt_to_page is redefined for CONFIG_GRKERNSEC_KSTACKOVERFLOW:
> 
> #define virt_to_page(kaddr)     \
>        ({ \
>                const void *__kaddr = (const void *)(kaddr); \
>                BUG_ON(!virt_addr_valid(__kaddr)); \
>                pfn_to_page(__pa(__kaddr) >> PAGE_SHIFT); \
>        })
> 
> So that's where the bug is hit. Now why is this happening?
> 
> I call scatterwalk_map_and_copy to read or write from or to a stack
> buffer

that's is your problem, DMA is forbidden to/from the stack in linux,
Documentation/DMA-API-HOWTO.txt says this:

   This rule also means that you may use neither kernel image addresses
   (items in data/text/bss segments), nor module image addresses, nor
   stack addresses for DMA.

> from a scattergather list, inside some crypto code that does
> MAC checking. When virt_addr_valid(__kaddr) returns false, it is only
> after PaX has additionally messed with its value. A few lines above
> the call to virt_to_page is:
> 
> #ifdef CONFIG_GRKERNSEC_KSTACKOVERFLOW
>        if (object_starts_on_stack(buf))
>                realbuf = buf - current->stack + current->lowmem_stack;
> #endif
> 
> Presumably this condition winds up being true, and then that
> arithmetic is wrong somehow. Alternatively, that condition isn't true
> due to a bug in object_starts_on_stack, and that arithmetic doesn't
> run when it needs to run.
> 
> Samuel reported that the problem did not exist on 4.7 but does exist
> on 4.8. If my memory serves me correctly, 4.8 introduced virtually
> mapped stacks. Could it be that this virtual mapping now eliminates
> the need for that arithmetic?

upstream will have 'virtually mapped stacks' (stupid name btw, stack is
always virtually mapped on MMU-capable systems :) as of 4.9 only, what
you're seeing above is grsec's KSTACKOVERFLOW feature which had a little
bonus added in 4.8 to handle (and detect the abuse of) IRQ stacks as well.

> Regards,
> Jason