From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 1C6722BAE; Mon, 30 Jan 2017 13:40:19 +0100 (CET) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP; 30 Jan 2017 04:40:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,311,1477983600"; d="scan'208";a="59102505" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga005.fm.intel.com with ESMTP; 30 Jan 2017 04:40:17 -0800 Date: Mon, 30 Jan 2017 20:42:41 +0800 From: Yuanhan Liu To: Emmanuel Roullit Cc: huawei.xie@intel.com, dev@dpdk.org, Thomas Monjalon , stable@dpdk.org Message-ID: <20170130124241.GF20916@yliu-dev.sh.intel.com> References: <20170124203603.3887-1-emmanuel.roullit@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170124203603.3887-1-emmanuel.roullit@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-stable] [PATCH] net/virtio: do not gso when no header is present X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 12:40:20 -0000 On Tue, Jan 24, 2017 at 09:36:03PM +0100, Emmanuel Roullit wrote: > Found with clang static analysis: > lib/librte_vhost/virtio_net.c:723:17: warning: > Access to field 'data_off' results in a dereference of a null pointer > (loaded from variable 'tcp_hdr') > m->l4_len = (tcp_hdr->data_off & 0xf0) >> 2; > ^~~~~~~~~~~~~~~~~ This is a good fix, thanks. But there are few minor nits. Firstly, prefix is wrong: it should be "vhost" but not "net/virtio". > Fixes: 2a51b1091cb5 ("vhost: support indirect descriptor in non-mergeable Rx") That's not the original commit introduced such issue, d0cf91303d73 ("vhost: add Tx offload capabilities") is. I actually saw you have made this kind of mistakes (referencing the wrong culprit commit) few times. I'm wondering how did you get that. Besides those, I think it's a good candidate for a stable release: thinking that a malicious guest might forge some invalid virtio net headers, which would make this potential NULL dereference become real. So, Cc: stable@dpdk.org, And Applied to dpdk-next-virtio. --yliu