Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp728349pxt; Fri, 6 Aug 2021 12:13:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyVLDyx7TmTIq53mQYAZcxy3dapAMplcrHEhy0OxJSs+6PRtijKAJ5GHYk6C4dJ2RI7+XAI X-Received: by 2002:aa7:c489:: with SMTP id m9mr15149078edq.256.1628277192886; Fri, 06 Aug 2021 12:13:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628277192; cv=none; d=google.com; s=arc-20160816; b=K/VIPfL08LiMMqv8rGsrSHm7SQTmYqNzOyb4ML8pMTUcNG+gjvEVYL73u69f5KTXgQ 31897ozyButpWhnn8r71JxRyT62EPn9Y01XCPDbKtIQFT+gx1U6GyFLzdBCiRu6fN1fV xmlg+82EV4i5pUJ88c4YjeuYFA+Ubve2bq0Cg/oU2j9tnI5k35yEsjQ0yNzQo4m18SKp GCUOsu8Qgkc5LMsyOX3sCwEoyBXGEULBt7JPORiiH15vMFtUMkKrtmP8tnwqaJIqSqHL gjoex0gMhhJogHZcWNE4cFV4hM5ne+QWcwOh3jUJxDuNA//gbqs55/4wC9nSE4VhVWS0 +xow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=pRzOebS1RbgFdOgWQ45BfUzG9C7P8200EQ3Kb32NO1g=; b=jl1aG93PB4En/TJ5UQX5lckJyzVkyb5BZ7Ppd9TystO9D+OX637ytFA+AQ0BNX5AkU jfuXruiqwoGB0HDsdznO5GcoNRS6nAS1NkM8PQdvVgMfaMv7+PQoLO9XI0wCuebGt/jM +/uBSqXTIP6ct7Xc+qY5VhiEyNjKFOFiz/6IPbuiLVMN1XWMJ/xNDSbVrGfMr79OX79H iQzCi5oLIjsdtCco6SH5Mx0I7hj/L8I6lTgeY5879g3cNgRy3BERMD9bmZy2LSXmaJsd i7V3I3V2FaJm5q4a3Rf9NxdDpmfAz55GN9AVaEhX4kZ/GO90S/2evOXV27zXISxofYSm qh0A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f12si9223250edw.528.2021.08.06.12.12.35; Fri, 06 Aug 2021 12:13:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343647AbhHFMPn (ORCPT + 99 others); Fri, 6 Aug 2021 08:15:43 -0400 Received: from out30-45.freemail.mail.aliyun.com ([115.124.30.45]:59656 "EHLO out30-45.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343589AbhHFMPl (ORCPT ); Fri, 6 Aug 2021 08:15:41 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R351e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04400;MF=xianting.tian@linux.alibaba.com;NM=1;PH=DS;RN=4;SR=0;TI=SMTPD_---0Ui8W5Kx_1628252123; Received: from localhost(mailfrom:xianting.tian@linux.alibaba.com fp:SMTPD_---0Ui8W5Kx_1628252123) by smtp.aliyun-inc.com(127.0.0.1); Fri, 06 Aug 2021 20:15:24 +0800 From: Xianting Tian To: jassisinghbrar@gmail.com Cc: linux-kernel@vger.kernel.org, guoren@kernel.org, Xianting Tian Subject: [PATCH] mailbox: fix a UAF bug in msg_submit() Date: Fri, 6 Aug 2021 20:15:21 +0800 Message-Id: <20210806121521.124365-1-xianting.tian@linux.alibaba.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We met a UAF issue during our mailbox testing. In synchronous mailbox, we use mbox_send_message() to send a message and wait for completion. mbox_send_message() calls msg_submit() to send the message for the first time, if timeout, it will send the message in tx_tick() for the second time. We assume message sending failed for both two times, then the message will be still in the internal buffer of a chan(chan->msg_data[idx]). It will be send again in the same way when mbox_send_message() is called next time. But, at this time this message (chan->msg_data[idx]) may be a UAF pointer, as the message is passed to mailbox core by user. User may free it after last calling of mbox_send_message() returned or not. Who knows!!! In this patch, if the first time sending timeout, we pass timeout info(-ETIME) to msg_submit() when do the second time sending by tx_tick(). If it still send failed (chan->mbox->ops->send_data() returned non-zero value) in the second time, we will give up this message(chan->msg_count--) sending. It doesn't matter, user can chose to send it again. Actually, the issue I described above doesn't exist if 'chan->mbox->ops->send_data()' always return 0. Because if it always returns 0, we will always do 'chan->msg_count—' regardless of message sending success or failure. We have such mailbox driver, for example, hi6220_mbox_send_data() always return 0. But we still have mailbox drivers, which don't always return 0, for example, flexrm_send_data() of drivers/mailbox/bcm-flexrm-mailbox.c. Signed-off-by: Xianting Tian --- drivers/mailbox/mailbox.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c index 3e7d4b20a..3e010aafa 100644 --- a/drivers/mailbox/mailbox.c +++ b/drivers/mailbox/mailbox.c @@ -50,7 +50,7 @@ static int add_to_rbuf(struct mbox_chan *chan, void *mssg) return idx; } -static void msg_submit(struct mbox_chan *chan) +static void msg_submit(struct mbox_chan *chan, int last_submit) { unsigned count, idx; unsigned long flags; @@ -75,7 +75,7 @@ static void msg_submit(struct mbox_chan *chan) chan->cl->tx_prepare(chan->cl, data); /* Try to submit a message to the MBOX controller */ err = chan->mbox->ops->send_data(chan, data); - if (!err) { + if (!err || last_submit == -ETIME) { chan->active_req = data; chan->msg_count--; } @@ -101,7 +101,7 @@ static void tx_tick(struct mbox_chan *chan, int r) spin_unlock_irqrestore(&chan->lock, flags); /* Submit next message */ - msg_submit(chan); + msg_submit(chan, r); if (!mssg) return; @@ -260,7 +260,7 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg) return t; } - msg_submit(chan); + msg_submit(chan, 0); if (chan->cl->tx_block) { unsigned long wait; -- 2.17.1