Messages in this thread | | | From | Dmitry Vyukov <> | Date | Tue, 6 Nov 2018 18:29:36 -0800 | Subject | Re: WARNING in kmem_cache_create_usercopy |
| |
On Fri, Nov 2, 2018 at 3:39 PM, Dominique Martinet <asmadeus@codewreck.org> wrote: > syzbot wrote on Fri, Nov 02, 2018: >> RIP: 0010:kmem_cache_create_usercopy+0xad/0x240 mm/slab_common.c:473 >> Code: 44 89 f0 25 00 60 de 04 45 85 ed 89 45 cc 75 0b 8b 45 d0 85 c0 >> 0f 85 8e 01 00 00 44 39 eb 72 0a 89 d8 44 29 e8 3b 45 d0 73 7e <0f> >> 0b c7 45 d0 00 00 00 00 4c 8b 45 10 44 89 fa 89 de 4c 89 e7 8b >> RSP: 0018:ffff8801bc23f5d0 EFLAGS: 00010213 >> RAX: 0000000000000000 RBX: 0000000000000008 RCX: 0000000000000006 >> RDX: 0000000000000000 RSI: 0000000000000020 RDI: ffffffff88b04b20 >> RBP: ffff8801bc23f608 R08: fffffbfff1283a2d R09: fffffbfff1283a2c >> R10: ffff8801bc23f5c0 R11: ffffffff8941d167 R12: ffffffff88b04b20 >> R13: 00000000fffffffd R14: 0000000000000000 R15: 0000000000000000 >> p9_client_create+0xa58/0x1769 net/9p/client.c:1054 > > No lower bound on msize, the reproducer gives a reply from the > pseudo-server with msize=8 and we happily take it, underflowing the > msize - 11 (hdr+4) argument to kmem_cache_create_usercopy... > This probably never worked anyway, but we now get a warning :) > > > We need to add a sane lower bound to msize as well as the current upper > bound set in the transport. > We have some header sizes in 9p.h for IO header overhead (P9_IOHDRSZ to > 24 for example) but I think that's too low in practice; stuff like > readdir will require more than this to get a single entry... We can > request the server to ask for at least 4k? > 9p would probably work with less (e.g. 1k; I'd rather not have to > figgure the minimum length we need to get each messages to work in its > minimal form) but honestly even with 4k the perforamnces will be > terrible, so tempted to go with that... > > I'll send a patch imposing 4k next week unless someone else does first, > or replies indicate different preferences. > > > @Dmitry: semi-related, the C reproducer ( > https://syzkaller.appspot.com/x/repro.c?x=1701f831400000 ) has a lot of > "readable" letters spelled out as "\x63..." or chars as 0x3d - it's fine > for generated code and that might be easier for the intermediate > representation syzkaller works with, but do you know something handy > that would help convert these to readable strings? > e.g. "\x63\x61\x63\x68\x65\x3d\xc0\x6d\x61\x70" could be written > "cache=\xc0map", and 0x3d as '=' (hm I guess the later would not always > make sense to convert so probably best left as is, but it gets annoying > pretty fast with longer strings)
Hi Dominique,
I've filed https://github.com/google/syzkaller/issues/792 for this.
Thanks for the feedback.
| |