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) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
