Received: by 10.192.165.148 with SMTP id m20csp1344221imm; Fri, 27 Apr 2018 18:09:19 -0700 (PDT) X-Google-Smtp-Source: AB8JxZp4HLURBiZa5mo+w5vjeFCPrT9gx0xtdUWn8GsfCXlwQA0UypFLxZQiq+TA9en/Assuvr+E X-Received: by 2002:a65:53c5:: with SMTP id z5-v6mr3886417pgr.413.1524877759581; Fri, 27 Apr 2018 18:09:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524877759; cv=none; d=google.com; s=arc-20160816; b=vvuPKtzCPsn1Vgn0FevvUKKuqmNMghADGfLBw34qOBMi0IM3j0yRabfWfg4mKv6KSI 7JMAPpAmy+X0oP5UYxd0cQIH3ovNfNYDCot79Hdma6is2NHdT1oFg6fV9mf43N/XQqa8 7s4OtAnaV8A+2uTTZ/HEINJINwXh+t5jVDFZt3CuykWG4YWDcemA3PSC8wFRiniaI3h/ OvnVBQDbCDR9/xjL28e1nD6Fq+lRojw1deUmNYp5xjB8bQoE34DzFxP49yx5K/3/Wu+O Vp11bxtWVWTQU24T+KjkAGAY3ZrgyKfQWFU2NiXNMA1KkzFn0taMZJq5nA2cbAXeJT0p XiMA== 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:arc-authentication-results; bh=XbpFss5fRWgpnzUhXLfiF6xB+3b5xm3I6UMMuthhwsc=; b=hdXPYdrMPMF2JCIXC43zVIDMXrELWwqfXiCoxYZ6p7voscmKmGw+WooAGSZA1zjQ34 iGCEHp4HsviGAjhVa+dv1uyIfjFjp3VQuz3hZR8rgMmiqKPjxN1XzWprPZ/AvVlUukoW o2F2BZRzAQUd/jWsmUjXuGkWjHfncrkJnWbu/6HLjVAUHUZ9FUpRXfB3dfiTdJboKuOg UwGv6B5wZSlzrSVRVminjhu69SUXXMf6hS29cVVgYOvZpV7jfJSV3V5hA4uP4c0AB3Q2 j9DT/hTeTVQ3EFf7ie/ljPu5KJ7kIzHiEsz7PzHz2V7RF6dcHk+Z5qI4YKhkqT5Q/jOD Q66A== 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 g67si2377958pfe.4.2018.04.27.18.09.05; Fri, 27 Apr 2018 18:09:19 -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 S1759474AbeD1BIA (ORCPT + 99 others); Fri, 27 Apr 2018 21:08:00 -0400 Received: from la.guarana.org ([173.254.219.205]:47838 "EHLO la.guarana.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759215AbeD1BH7 (ORCPT ); Fri, 27 Apr 2018 21:07:59 -0400 Received: by la.guarana.org (Postfix, from userid 1006) id 9FFE334606E7; Fri, 27 Apr 2018 21:07:56 -0400 (EDT) Date: Fri, 27 Apr 2018 21:07:56 -0400 From: Kevin Easton To: "Michael S. Tsirkin" Cc: Jason Wang , kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Subject: Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node Message-ID: <20180428010756.GA27341@la.guarana.org> References: <000000000000a5b2b1056a86e98c@google.com> <20180427154502.GA22544@la.guarana.org> <20180427185501-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180427185501-mutt-send-email-mst@kernel.org> 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 On Fri, Apr 27, 2018 at 07:05:45PM +0300, Michael S. Tsirkin wrote: > On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote: > > The struct vhost_msg within struct vhost_msg_node is copied to userspace, > > so it should be allocated with kzalloc() to ensure all structure padding > > is zeroed. > > > > Signed-off-by: Kevin Easton > > Reported-by: syzbot+87cfa083e727a224754b@syzkaller.appspotmail.com > > Does it help if a patch naming the padding is applied, > and then we init just the relevant field? > Just curious. No, I don't believe that is sufficient to fix the problem. The structure is allocated by kmalloc(), then individual fields are initialised. The named adding would be forced to be initialised if it were initialised with a struct initialiser, but that's not the case. The compiler is free to leave padding0 with whatever junk kmalloc() left there. Having said that, naming the padding *does* help - technically, the compiler is allowed to put whatever it likes in the padding every time you modify the struct. It really needs both. I didn't name the padding in my original patch because I wasn't sure if the padding actually exists on 32 bit architectures? - Kevin