Re: HARDENED_USERCOPY will BUG on multiple slub objects coalesced into an sk_buff fragment

[Christopher Lameter <cl@linux.com>]

On Fri, 1 Jun 2018, Matthew Wilcox wrote:

> > >> My take on the root cause:
> > >>    When adding data to an skb, new data is appended to the current
> > >> fragment if the new chunk immediately follows the last one: by simply
> > >> increasing the frag->size, skb_frag_size_add().
> > >>    See include/linux/skbuff.h:skb_can_coalesce() callers.
> >
> > Oooh, sneaky:
> >                 return page == skb_frag_page(frag) &&
> >                        off == frag->page_offset + skb_frag_size(frag);
> >
> > Originally I was thinking that slab red-zoning would get triggered
> > too, but I see the above is checking to see if these are precisely
> > neighboring allocations, I think.
> >
> > But then ... how does freeing actually work? I'm really not sure how
> > this seeming layering violation could be safe in other areas?

So if there are two neighboring slab objects that the page struct
addresses will match and the network code will coalesce the objects even
if they are in two different slab objects?

The check in skb_can_coalesce() must verify that these are distinct slab
object. Simple thing would be to return false if one object is a slab
object but then the coalescing would not work in a single slab object
either.

So what needs to happen is that we need to check if this is

1) A Page. Then the proper length of the segment within we can coalesce is
the page size.

2) A slab page. Then we can use ksize() to establish the end of the slab
object and we should only coalesce within that boundary.