From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sagigrim@gmail.com>
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
 by dpdk.org (Postfix) with ESMTP id EFCCB2BE2
 for <dev@dpdk.org>; Tue,  2 Aug 2016 11:31:37 +0200 (CEST)
Received: by mail-wm0-f51.google.com with SMTP id o80so280706906wme.1
 for <dev@dpdk.org>; Tue, 02 Aug 2016 02:31:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:subject:references:cc:to:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-transfer-encoding;
 bh=6XbQtUoq4aNjCq/YcWTiP/lNy/kRgD6UD+DXaW+a1V8=;
 b=mmafVC/NRc/JMMJjq2qjY/DVHXXqcDJ0V7ZtubFJdwVREjrUxQQDFpHdYZiQ4/Ksye
 tc32pBAz7qQAQPa/puIUw5nFrhJUqd76tYCVB1WMXh8PN0g2LYTyEUdSCRjCij8Zoah7
 eqplTGd27wPvykVruh/jWEYLWAaIAriVxmArnn0pYTluLP4jhQkdzvf5dwd/LuK69snx
 2sA4FJ4+1zt+V7K0TWzkIJiaQO/T4IsjyVC1vmiHbKHvICzhqd9qfE4QnGLQwp5F8fI9
 RL1cztiEbbabYAsFyk5IRZYwBkmxIJJUYGd3xt04p1oIMKa48vNMVeqVY+qWuCIIeLKY
 VK6g==
X-Gm-Message-State: AEkoouuIF6v/YA3/BH4/EEEbhdBkj55jg9AqenTDQb9QHEDyq2FLo4lBK3M5oVsUGEZDkA==
X-Received: by 10.194.143.17 with SMTP id sa17mr51659765wjb.97.1470130297688; 
 Tue, 02 Aug 2016 02:31:37 -0700 (PDT)
Received: from [192.168.1.204] (bzq-82-81-101-184.red.bezeqint.net.
 [82.81.101.184])
 by smtp.gmail.com with ESMTPSA id p4sm1671498wjq.27.2016.08.02.02.31.36
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 02 Aug 2016 02:31:36 -0700 (PDT)
References: <1470041061-8059-1-git-send-email-sagi@grimberg.me>
 <20160801164342.GL9044@6wind.com>
Cc: dev@dpdk.org
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>
From: Sagi Grimberg <sagi@grimberg.me>
Message-ID: <0e002bcc-017b-8d5e-f820-111f5c3a7b46@grimberg.me>
Date: Tue, 2 Aug 2016 12:31:35 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160801164342.GL9044@6wind.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH] net/mlx5: Fix possible NULL deref in RX path
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2016 09:31:38 -0000



On 01/08/16 19:43, Adrien Mazarguil wrote:
> Hi Sagi,
>
> On Mon, Aug 01, 2016 at 11:44:21AM +0300, Sagi Grimberg wrote:
>> The user is allowed to call ->rx_pkt_burst() even without free
>> mbufs in the pool. In this scenario we'll fail allocating a rep mbuf
>> on the first iteration (where pkt is still NULL). This would cause us
>> to deref a NULL pkt (reset refcount and free).
>>
>> Fix this by checking the pkt before freeing it.
>
> Just to be sure, did you get an actual NULL deref crash here or is that an
> assumed possibility?
>
> I'm asking because this problem was supposed to be addressed by:
>
>  a1bdb71a32da ("net/mlx5: fix crash in Rx")

I actually got the NULL deref. This happens when the application doesn't
restore mbufs to the pool correctly. In the case rte_mbuf_raw_alloc
will fail on the first iteration (pkt wasn't assigned) unlike the
condition handled in a1bdb71a32da.

With this applied, I didn't see the crash.