Re: BUG: bad usercopy in memdup_user

[Dmitry Vyukov]

On Wed, Dec 20, 2017 at 10:44 AM, David Laight <David.Laight@xxxxxxxxxx> wrote:
> From: Al Viro
>> Sent: 19 December 2017 21:49
>> > I suspect that an "offset and size within the kernel object" value
>> > might make sense.  But what does the _pointer_ tell you?
>>
>> Well, for example seeing a 0xfffffffffffffff4 where a pointer to object
>> must have been is a pretty strong hint to start looking for a way for
>> that ERR_PTR(-ENOMEM) having ended up there...  Something like
>> 0x6e69622f7273752f is almost certainly a misplaced "/usr/bin", i.e. a
>> pathname overwriting whatever it ends up in, etc.  And yes, I have run
>> into both of those in real life.
>>
>> Debugging the situation when crap value has ended up in place of a
>> pointer is certainly a case where you do want to see what exactly has
>> ended up in there...
>
> I've certainly seen a lot of ascii in pointers (usually because the
> previous item has overrun).
> Although I suspect they'd appear in the fault frame - which hopefully
> carries real addresses.
>
> A compromise would be to hash the 'page' part of the address.
> On 64bit systems this is probably about 32 bits.
> It would still show whether pointers are user, kernel, vmalloc (etc)
> but without giving away the actual value.
> The page offset (12 bits) would show the alignment (etc).
>
> Including a per-boot random number would make it harder to generate
> 'rainbow tables' to reverse the hash.


Bad things on kmalloc-1024 are most likely caused by an invalid free
in pcrypt, it freed a pointer into a middle of a 1024 byte heap object
which was undetected by KASAN (now there is a patch for this in mm
tree) and later caused all kinds of bad things:
https://groups.google.com/forum/#!topic/syzkaller-bugs/NKn_ivoPOpk
https://patchwork.kernel.org/patch/10126761/

#syz dup: KASAN: use-after-free Read in __list_del_entry_valid (2)