From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
[66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 0440E5424
for <dev@dpdk.org>; Thu, 22 Nov 2018 23:10:03 +0100 (CET)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailout.nyi.internal (Postfix) with ESMTP id 7D41822077;
Thu, 22 Nov 2018 17:10:03 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
by compute1.internal (MEProxy); Thu, 22 Nov 2018 17:10:03 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
from:to:cc:subject:date:message-id:in-reply-to:references
:mime-version:content-transfer-encoding:content-type; s=mesmtp;
bh=vQ2XF3JjsOqb6h1hSJUwthi9lCfA5U5B8CVin0KfOSw=; b=opE6rciGef5E
cixo5bIL+VrOjAaV08DW+RPKrJ7Fa8MMV/9t57F5k1bYyKf2zctrLSmV1Dro/bGJ
8yL+KVKIPhYHg4fm9/oRbWPrn0QspYlfiwaR1JDdj2DO0pZ7s89AazHi6isDd1jp
IP49H2ubQj+2qx3AlqJ3ap4h2XOpXHM=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
:x-sasl-enc; s=fm1; bh=vQ2XF3JjsOqb6h1hSJUwthi9lCfA5U5B8CVin0KfO
Sw=; b=WjuJDY+2WeYDRhMUb6Ky6P87WH0J1zU7zybbri+e2PuKNd3YBBDSMdWvF
BE7zCyg3V+Fb71+0aMdBM2ezlnWOWVke6BOW83EYM9IU4jRO2yDygD+Lqe4tZv37
5PkEEykCVCnmpqb5MXJM/GyDGbHXHzsduGe9PMWaOQOXXcFSfFsseKrwoAOXTyuz
5lHoDUJpqXmtk4QlGQwPvdsRnUg4cqjnrP1e5/PkNz1Igv8BtiD8r0ZmoLwG0fBZ
gCCpQKzWYuy1uVJSe1YmkCaqEqGA4vg/tg7wna54Kt991kgTUqu1YInZnOI3UaEF
eemQRGk02wYUawMTdsUuXvNLmEFrw==
X-ME-Sender: <xms:Oin3Wx1Mxn4D3r9pT587NqbZXICQv3C_IPkoPvlW4RgS9q5wS27tcw>
X-ME-Proxy: <xmx:Oin3W-l2MnYnWgyoWfpKSgQhGv6bLPOTcBMp2Rr9Y1_qCdOnhim27A>
<xmx:Oin3W9Bm2o3LMks0hxs1LODikYQvzEgvgKvfx5Je2TMXl6XxTb4ZDw>
<xmx:Oin3W70GaahomhC1-PuVGjGMs-L4FTlCVxI_abJ89Ow6CzxUohcSrg>
<xmx:Oin3W0DNzRbOu8FIg52ILXqWJRhkLONdkWipxLW10w3yFaUO2w-1rw>
<xmx:Oin3WyMOMzEdigKMetWWJsprb288R6S4HDsaaDmQLpZM7em1YEmHVg>
<xmx:Oyn3WyJcPgTfo0niMGM-r-J3asXDTmkIPv6VuHV8bHa60bdkbFLzwQ>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
by mail.messagingengine.com (Postfix) with ESMTPA id CBBD8102A0;
Thu, 22 Nov 2018 17:10:01 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: Anatoly Burakov <anatoly.burakov@intel.com>
Cc: dev@dpdk.org
Date: Thu, 22 Nov 2018 23:09:57 +0100
Message-ID: <3087286.9lSO7AOfn4@xps>
In-Reply-To: <69497bc41646c6dd5eebb097b3bdc8a2136aeb53.1542730524.git.anatoly.burakov@intel.com>
References: <3ac0562bbdfbabbcb2bdf5fec9e0ffa777475e2b.1542727150.git.anatoly.burakov@intel.com>
<69497bc41646c6dd5eebb097b3bdc8a2136aeb53.1542730524.git.anatoly.burakov@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH v2] ipc: fix use-after-free on failed send
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Nov 2018 22:10:04 -0000
20/11/2018 17:18, Anatoly Burakov:
> Previous fix for rte_panic has moved setting of alarm before
> sending the message. This means that whether we send a message,
> the alarm would still trigger. The comment noted that cleanup
> would happen in the alarm handler, but that's not what actually
> happened - instead, in the event of failed send we freed the
> memory in-place, before putting the request on the queue.
>
> This works OK when the message is sent, but when sending the
> message fails, the alarm would still trigger with a pointer
> argument that points to non-existent memory, and cause
> memory corruption.
>
> There probably is a "proper" fix for this issue, with correct
> handling of sent vs. unsent requests, however it would be
> simpler just to sacrifice the sent request in the (extremely
> unlikely) event of alarm set failing. The other process would
> still send a response, but it will be ignored by the sender.
>
> Fixes: 45e5f49e87fb ("ipc: remove panic in async request")
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Applied, thanks