Received: by 10.192.165.148 with SMTP id m20csp1371272imm; Fri, 27 Apr 2018 18:52:37 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpfgCPBijd2zWswrDkPlFvL/1/mMyP/5dRTtY1YBRUmJ7koBmaqsJgXWvPQTErSDkSaTdii X-Received: by 2002:a65:6205:: with SMTP id d5-v6mr3923885pgv.416.1524880357410; Fri, 27 Apr 2018 18:52:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524880357; cv=none; d=google.com; s=arc-20160816; b=JDJgL9XZ5LJ35MIQ++77ZAVJhTZmeVbQarOwJqmgjpIJsKvzhPu9IRmpr090AhETEA xZraTJj+gk2uXa2ifn5MiFUZV4KoCuglEFTPySHP2A5ZjDKPCRFumprTwXPuZ6MU2/Fi ele75cWPKaa5oXXTSNgOQrYVJ/Mf8r8jMvbtc3eijsEjGegDDZ4ZgyhK7AtN38uUt535 Agn49ix/Rnc4cCCaOkTWnN50YeOnnkaXeVlH9qQdSoztYQsaASZNgEmLPl24IWYDbNLo XAFInSLXpJqL1nUsNH1C02mSfIjIDAsC8synLHBUjb5TvGr9iOpKLsFyatyZ5f1BzSTm FCgA== 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=eL2w8oCdgmmmFGGXtWwPEuYMRYcJ6ndpQBcbQfCjdCM=; b=hbKjvYnXlNAeqkap+GHpNxlcoa3+MkIHSI6sixNoS++fXOZ4tZnfa+o2c1thtwWFt1 ldPbFjZ3I52pXjtD0fE8JUZp9juXvntEFXusewbWe6kS7vlTaPz75GLTPpTZXX2fqNj0 B/JYEXxpguhEUh+YXJAjV4jTF+AW8BqF6uLL+bK5LxAw7MAVU0cSi+qmqBGuzNzVGZwN LlPqMeb5joqjDXgOX6AMJzRwz7IhdP5FXcda6VX02sPD4vuVyr++QAP60AXf4OcXZFst Vnp7b0W0B+om5vXqmVSofp/JvXu1IFBRuLG1dlMsqO0sJjJnygv7Ffmqr2rgs7C/pQ+L f05g== 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 n23-v6si2273590pgc.359.2018.04.27.18.52.22; Fri, 27 Apr 2018 18:52:37 -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 S933319AbeD1BvI (ORCPT + 99 others); Fri, 27 Apr 2018 21:51:08 -0400 Received: from la.guarana.org ([173.254.219.205]:59832 "EHLO la.guarana.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933263AbeD1BvG (ORCPT ); Fri, 27 Apr 2018 21:51:06 -0400 Received: by la.guarana.org (Postfix, from userid 1006) id 6BA6234606E7; Fri, 27 Apr 2018 21:51:06 -0400 (EDT) Date: Fri, 27 Apr 2018 21:51:06 -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: <20180428015106.GA27738@la.guarana.org> References: <000000000000a5b2b1056a86e98c@google.com> <20180427154502.GA22544@la.guarana.org> <20180427185501-mutt-send-email-mst@kernel.org> <20180428010756.GA27341@la.guarana.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180428010756.GA27341@la.guarana.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 09:07:56PM -0400, Kevin Easton wrote: > 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. Scratch that, somehow I missed the "..and then we init just the relevant field" part, sorry. There's still the padding after the vhost_iotlb_msg to consider. It's named in the union but I don't think that's guaranteed to be initialised when the iotlb member of the union is used to initialise things. > I didn't name the padding in my original patch because I wasn't sure > if the padding actually exists on 32 bit architectures? This might still be a concern, too? At the end of the day, zeroing 96 bytes (the full size of vhost_msg_node) is pretty quick. - Kevin