linux-kernel - Re: WARNING in kmem_cache_create

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+bu52epUKjx5PEQBmhuvjA-wk8xbO4XpeAYHHZZkxAn3w@mail.gmail.com>
Date:   Tue, 6 Nov 2018 18:29:36 -0800
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Dominique Martinet <asmadeus@...ewreck.org>
Cc:     syzbot <syzbot+0c1d61e4db7db94102ca@...kaller.appspotmail.com>,
        David Miller <davem@...emloft.net>,
        Eric Van Hensbergen <ericvh@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Latchesar Ionkov <lucho@...kov.net>,
        netdev <netdev@...r.kernel.org>, syzkaller-bugs@...glegroups.com,
        v9fs-developer@...ts.sourceforge.net
Subject: Re: WARNING in kmem_cache_create_usercopy

On Fri, Nov 2, 2018 at 3:39 PM, Dominique Martinet
<asmadeus@...ewreck.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.