Messages in this thread |  | | From | Dmitry Vyukov <> | Date | Sun, 31 Dec 2017 09:11:05 +0100 | Subject | Re: BUG: bad usercopy in memdup_user |
| |
On Wed, Dec 20, 2017 at 10:44 AM, David Laight <David.Laight@aculab.com> 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)
|  |