DPDK patches and discussions
 help / color / mirror / Atom feed
From: Anatoly Burakov <anatoly.burakov@intel.com>
To: dev@dpdk.org
Cc: thomas@monjalon.net
Subject: [dpdk-dev] [PATCH v2] ipc: fix use-after-free on failed send
Date: Tue, 20 Nov 2018 16:18:46 +0000	[thread overview]
Message-ID: <69497bc41646c6dd5eebb097b3bdc8a2136aeb53.1542730524.git.anatoly.burakov@intel.com> (raw)
In-Reply-To: <3ac0562bbdfbabbcb2bdf5fec9e0ffa777475e2b.1542727150.git.anatoly.burakov@intel.com>

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>
---

Notes:
    v2:
    - Move incrementing of nb_sent to before setting the alarm. This will
      let the API consumers know that some messages were sent, but failed
      to receive a response (due to failure of IPC to set the alarm).

 lib/librte_eal/common/eal_common_proc.c | 40 ++++++++-----------------
 1 file changed, 13 insertions(+), 27 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_proc.c b/lib/librte_eal/common/eal_common_proc.c
index f65ef56c0..1c3f09aad 100644
--- a/lib/librte_eal/common/eal_common_proc.c
+++ b/lib/librte_eal/common/eal_common_proc.c
@@ -827,20 +827,19 @@ mp_request_async(const char *dst, struct rte_mp_msg *req,
 		goto fail;
 	}
 
-	/*
-	 * set the alarm before sending message. there are two possible error
-	 * scenarios to consider here:
-	 *
-	 * - if the alarm set fails, we free the memory right there
-	 * - if the alarm set succeeds but sending message fails, then the alarm
-	 *   will trigger and clean up the memory
-	 *
-	 * Even if the alarm triggers too early (i.e. immediately), we're still
-	 * holding the lock to pending requests queue, so the interrupt thread
-	 * will just spin until we release the lock, and either release the
-	 * memory, or doesn't find any pending requests in the queue because we
-	 * never added any due to send message failure.
-	 */
+	ret = send_msg(dst, req, MP_REQ);
+	if (ret < 0) {
+		RTE_LOG(ERR, EAL, "Fail to send request %s:%s\n",
+			dst, req->name);
+		ret = -1;
+		goto fail;
+	} else if (ret == 0) {
+		ret = 0;
+		goto fail;
+	}
+	param->user_reply.nb_sent++;
+
+	/* if alarm set fails, we simply ignore the reply */
 	if (rte_eal_alarm_set(ts->tv_sec * 1000000 + ts->tv_nsec / 1000,
 			      async_reply_handle, pending_req) < 0) {
 		RTE_LOG(ERR, EAL, "Fail to set alarm for request %s:%s\n",
@@ -848,21 +847,8 @@ mp_request_async(const char *dst, struct rte_mp_msg *req,
 		ret = -1;
 		goto fail;
 	}
-
-	ret = send_msg(dst, req, MP_REQ);
-	if (ret < 0) {
-		RTE_LOG(ERR, EAL, "Fail to send request %s:%s\n",
-			dst, req->name);
-		ret = -1;
-		goto fail;
-	} else if (ret == 0) {
-		ret = 0;
-		goto fail;
-	}
 	TAILQ_INSERT_TAIL(&pending_requests.requests, pending_req, next);
 
-	param->user_reply.nb_sent++;
-
 	return 0;
 fail:
 	free(pending_req);
-- 
2.17.1

  reply	other threads:[~2018-11-20 16:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-20 15:23 [dpdk-dev] [PATCH] " Anatoly Burakov
2018-11-20 16:18 ` Anatoly Burakov [this message]
2018-11-22 22:09   ` [dpdk-dev] [PATCH v2] " Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=69497bc41646c6dd5eebb097b3bdc8a2136aeb53.1542730524.git.anatoly.burakov@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).