Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp2663443imd; Fri, 2 Nov 2018 15:41:03 -0700 (PDT) X-Google-Smtp-Source: AJdET5cXJSn821yptK6vr94JOu+VcMd9nYO8vC7gQobsfQ3KS6lJSe+KwWe/2kdKqrGN1KD/R9oj X-Received: by 2002:a63:e348:: with SMTP id o8mr12295241pgj.158.1541198463183; Fri, 02 Nov 2018 15:41:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541198463; cv=none; d=google.com; s=arc-20160816; b=LdRStS+Xw5MHAxCyRVyreJF5lCKkG8sdhb9foRouTTEgtdtNnzn+dwjzImwTsfkJqZ GEr5OYcbcVt9RLmxfGTVrO8UfEDkJfzlfF7KChIqzj0miRwxLDooslQFLiYLxYFXwzVs vRnXHwKiDQMJVMy1L7M/9auXKA35yUqw+BmXozC8G5SOM6fPecyGnJ0yaX2NNCEnOKNn SC65W5f6OFc0z7Lif9g1297rmjzSe50vvUnSCQ0jofkhtgOzt6iPM9R+7flB8HT8wDhQ hqTy/sWCJmEovntjucdjHGk0U/HuHpGuST2FiiyysqBaHUEbRPwhpovXUf21s3Z2sKfq 8RZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=sdRb0yyyUuRNY59v+pq27JOzsIYdVW4CY6BC3ea/UAs=; b=KuMF/lAJjSweKIr1pSOhr8UA8djblO0eU0wuvxcbdY/37BgVX3V8ao+zOrNl2NMRAx CktAFwLEHP+SNL0EUsRlXWEUDRmod2CTHAh0B2TQ16suQ4yV2TtUU9u9RKZ2HIaA8/AH gpjAASjP4vdF+qnuEFYgYvlzLfK3E6xkebJWF4edQqTDbE2DTO1llnA0C1Tl6xUlOiH0 HvNIjyELO4y/JAxObt+SZ7t7b5shIbCh/2MDCzpRR4odl16MMNQTMZPOAbRq4U8PeAuG KaK6k7k0UnIX3pq5L908G/HQZLig+/zO5NgYvVw+iRuHHe6Vx5dUyKZWLWalLnoW9/6s 7s5w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 27si5769926pgp.135.2018.11.02.15.40.34; Fri, 02 Nov 2018 15:41:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728453AbeKCHs0 (ORCPT + 99 others); Sat, 3 Nov 2018 03:48:26 -0400 Received: from nautica.notk.org ([91.121.71.147]:32895 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726729AbeKCHs0 (ORCPT ); Sat, 3 Nov 2018 03:48:26 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id F41ECC009; Fri, 2 Nov 2018 23:39:23 +0100 (CET) Date: Fri, 2 Nov 2018 23:39:08 +0100 From: Dominique Martinet To: syzbot Cc: davem@davemloft.net, ericvh@gmail.com, linux-kernel@vger.kernel.org, lucho@ionkov.net, netdev@vger.kernel.org, syzkaller-bugs@googlegroups.com, v9fs-developer@lists.sourceforge.net Subject: Re: WARNING in kmem_cache_create_usercopy Message-ID: <20181102223908.GA9565@nautica> References: <0000000000009d4c780579b04ee4@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0000000000009d4c780579b04ee4@google.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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) -- Dominique