Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp239235ybj; Fri, 8 May 2020 10:36:19 -0700 (PDT) X-Google-Smtp-Source: APiQypL3vvqLHKIzFu7UGisNRil/RH3fXuqn2ojl/guSnT8ZMjwdKI3b/Du381sv2N+LwypgA0mI X-Received: by 2002:a05:6402:1d1c:: with SMTP id dg28mr3122730edb.315.1588959379588; Fri, 08 May 2020 10:36:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588959379; cv=none; d=google.com; s=arc-20160816; b=dGjDJvn1ublPUZ5SUCOjH1wsiHRAKXG92zSZcfxH/KPTdpdkd2Ej9cUGbX8OQDhDa8 CjtHy38GnJ0KfkUny/yFWPV0rgBQphFEty6yruSpnj3Hu8Gwi/SME/YnpbzkMsqSw2VR QaollPnpHAXxdUxX6/4pReOIv9etz+bZ8eKQD4n2/YXDszCKEECu/eVMhdjYCRmaHwjC gii1aKw+FlrQxb//WA+q/m9U+/H6kRfdLOt5EtK5Ojxo/AFPTggKWnDjlu04H8+HjzK4 J6uL/CKSWq2sH0/+F16PEPShV1LBIN6Oxihe71YKly5n9WAJYf+4KOxk2vUMuVnX7f0u EKtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature; bh=YRdx5B97TVorxMXPiXfW7wmYxuXC8t3jsBBMWPO3mPk=; b=QLcLu62LRmjE8tx+cEtS6SY+FwlFZJjA9Zqzy/M3cExXqffjEciNW9zecNRx17drXL U98nKY23c/txeGruMTaMszV430Rp03Aqg3xWyw+AHZ/WKxzZ9v+ygMSgPXnIyg1bX/yI UVUpEu4O6N6Xw3/852h0uR2+NTR6EvZd6/7pkq/Q6RTv8pOirRSATrIKXJSkYgyTI+1k kozLrrOHp6e5fFfdKNxXCQ97oqQ+GJNMQyfg8W7PWfBwkIC5qSaO79AXLykwzL1gK3v7 tsCgdqk8UDmO1agwrotjryBIWuez1zxPZoi0o0M139R2+OHWE0YBmz3pmzQ908VUh8Gq rTww== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=RzHyM5dG; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j23si1268460ejm.361.2020.05.08.10.35.56; Fri, 08 May 2020 10:36:19 -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; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=RzHyM5dG; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726908AbgEHRed (ORCPT + 99 others); Fri, 8 May 2020 13:34:33 -0400 Received: from mail27.static.mailgun.info ([104.130.122.27]:18375 "EHLO mail27.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726797AbgEHRed (ORCPT ); Fri, 8 May 2020 13:34:33 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1588959272; h=Content-Transfer-Encoding: Content-Type: In-Reply-To: MIME-Version: Date: Message-ID: From: References: Cc: To: Subject: Sender; bh=YRdx5B97TVorxMXPiXfW7wmYxuXC8t3jsBBMWPO3mPk=; b=RzHyM5dG0pAj7fF5D0GKQyT2zERsO0gOJRDsTL3RKe/JPDVjU3QrWTsctkDFi03fG0YHqH8d 6zSzSVRdk+3pPUOKBIC2gnY00TM3gwbSyOksVKORcJFv1a4CEYcgsN526tHqysjzwlthIlPK W4fLo3/o1tegBWv/xYR1GMUrU/Y= X-Mailgun-Sending-Ip: 104.130.122.27 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by mxa.mailgun.org with ESMTP id 5eb59817.7fc768bbdfb8-smtp-out-n03; Fri, 08 May 2020 17:34:15 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 259E7C433BA; Fri, 8 May 2020 17:34:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED,SPF_NONE autolearn=ham autolearn_force=no version=3.4.0 Received: from [10.46.162.249] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: hemantk) by smtp.codeaurora.org (Postfix) with ESMTPSA id 64005C433F2; Fri, 8 May 2020 17:34:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 64005C433F2 Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=none smtp.mailfrom=hemantk@codeaurora.org Subject: Re: [PATCH v6 3/8] bus: mhi: core: Add range check for channel id received in event ring To: Manivannan Sadhasivam , Bhaumik Bhatt Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, jhugo@codeaurora.org References: <1588718832-4891-1-git-send-email-bbhatt@codeaurora.org> <1588718832-4891-4-git-send-email-bbhatt@codeaurora.org> <20200508054518.GA2696@Mani-XPS-13-9360> From: Hemant Kumar Message-ID: <82e131f8-8c67-23c3-3ac2-a05eb04d50ba@codeaurora.org> Date: Fri, 8 May 2020 10:34:13 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20200508054518.GA2696@Mani-XPS-13-9360> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mani, On 5/7/20 10:45 PM, Manivannan Sadhasivam wrote: > On Tue, May 05, 2020 at 03:47:07PM -0700, Bhaumik Bhatt wrote: >> From: Hemant Kumar >> >> MHI data completion handler function reads channel id from event >> ring element. Value is under the control of MHI devices and can be >> any value between 0 and 255. In order to prevent out of bound access >> add a bound check against the max channel supported by controller >> and skip processing of that event ring element. >> >> Signed-off-by: Hemant Kumar >> Signed-off-by: Bhaumik Bhatt >> Reviewed-by: Jeffrey Hugo >> --- >> drivers/bus/mhi/core/main.c | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c >> index 605640c..e60ab21 100644 >> --- a/drivers/bus/mhi/core/main.c >> +++ b/drivers/bus/mhi/core/main.c >> @@ -776,6 +776,9 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller *mhi_cntrl, >> case MHI_PKT_TYPE_TX_EVENT: >> chan = MHI_TRE_GET_EV_CHID(local_rp); >> mhi_chan = &mhi_cntrl->mhi_chan[chan]; > > Check should be done before this statement, isn't it? my bad. thanks for pointing that out. > >> + if (WARN_ON(chan >= mhi_cntrl->max_chan)) >> + goto next_event; >> + > > I don't prefer using gotos for non exit paths but I don't have a better solution > here. But you can try to wrap 'WARN_ON' inside the 'MHI_TRE_GET_EV_CHID' > definition and the just use: Instead of moving WARN_ON to macro as it requires mhi_cntrl->max_chan to compare, how about just adding WARN_ON statement above if condition like this WARN_ON(chan >= mhi_cntrl->max_chan); /* * Only process the event ring elements whose channel * ID is within the maximum supported range. */ if (chan < mhi_cntrl->max_chan) { mhi_chan = &mhi_cntrl->mhi_chan[chan]; parse_xfer_event(mhi_cntrl, local_rp, mhi_chan); event_quota--; } break; > > /* > * Only process the event ring elements whose channel > * ID is within the maximum supported range. > */ > if (chan < mhi_cntrl->max_chan) { > mhi_chan = &mhi_cntrl->mhi_chan[chan]; > parse_xfer_event(mhi_cntrl, local_rp, mhi_chan); > event_quota--; > } > break; > > This looks more clean. > >> parse_xfer_event(mhi_cntrl, local_rp, mhi_chan); >> event_quota--; >> break; >> @@ -784,6 +787,7 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller *mhi_cntrl, >> break; >> } >> >> +next_event: >> mhi_recycle_ev_ring_element(mhi_cntrl, ev_ring); >> local_rp = ev_ring->rp; >> dev_rp = mhi_to_virtual(ev_ring, er_ctxt->rp); > > So you want the count to get increased for skipped element also? yeah idea is to have total count of events processed even if channel id is not correct for that event. This fix is a security fix considering that the MHI device is considered as non-secured and MHI host is trying to continue function normally and just reporting it as warning. > > Thanks, > Mani > >> @@ -820,6 +824,9 @@ int mhi_process_data_event_ring(struct mhi_controller *mhi_cntrl, >> enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp); >> >> chan = MHI_TRE_GET_EV_CHID(local_rp); >> + if (WARN_ON(chan >= mhi_cntrl->max_chan)) >> + goto next_event; >> + >> mhi_chan = &mhi_cntrl->mhi_chan[chan]; >> >> if (likely(type == MHI_PKT_TYPE_TX_EVENT)) { >> @@ -830,6 +837,7 @@ int mhi_process_data_event_ring(struct mhi_controller *mhi_cntrl, >> event_quota--; >> } >> >> +next_event: >> mhi_recycle_ev_ring_element(mhi_cntrl, ev_ring); >> local_rp = ev_ring->rp; >> dev_rp = mhi_to_virtual(ev_ring, er_ctxt->rp); Even this function has the same goto statement. For consistency i would do same thing here as well. Let me know what do you think about above suggestion for both functions. >> -- >> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, >> a Linux Foundation Collaborative Project >> -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project