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;
Date:   Mon, 31 Aug 2020 01:25:49 +0300
From:   Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To:     Jia-Ju Bai <baijiaju@tsinghua.edu.cn>
Cc:     Pavel Machek <pavel@ucw.cz>, Sasha Levin <sashal@kernel.org>,
        linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        Sean Young <sean@mess.org>,
        Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
        linux-media@vger.kernel.org
Subject: Re: [PATCH AUTOSEL 4.19 08/38] media: pci: ttpci: av7110: fix
 possible buffer overflow caused by bad DMA value in debiirq()
Message-ID: <20200830222549.GD6043@pendragon.ideasonboard.com>
References: <20200821161807.348600-1-sashal@kernel.org>
 <20200821161807.348600-8-sashal@kernel.org>
 <20200829121020.GA20944@duo.ucw.cz>
 <20200829171600.GA7465@pendragon.ideasonboard.com>
 <9e797c3a-033b-3473-ac03-1566d40e90d2@tsinghua.edu.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <9e797c3a-033b-3473-ac03-1566d40e90d2@tsinghua.edu.cn>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Jia-Ju,

On Sun, Aug 30, 2020 at 03:33:11PM +0800, Jia-Ju Bai wrote:
> On 2020/8/30 1:16, Laurent Pinchart wrote:
> > On Sat, Aug 29, 2020 at 02:10:20PM +0200, Pavel Machek wrote:
> >> Hi!
> >>
> >>> The value av7110->debi_virt is stored in DMA memory, and it is assigned
> >>> to data, and thus data[0] can be modified at any time by malicious
> >>> hardware. In this case, "if (data[0] < 2)" can be passed, but then
> >>> data[0] can be changed into a large number, which may cause buffer
> >>> overflow when the code "av7110->ci_slot[data[0]]" is used.
> >>>
> >>> To fix this possible bug, data[0] is assigned to a local variable, which
> >>> replaces the use of data[0].
> >> I'm pretty sure hardware capable of manipulating memory can work
> >> around any such checks, but...
> >>
> >>> +++ b/drivers/media/pci/ttpci/av7110.c
> >>> @@ -424,14 +424,15 @@ static void debiirq(unsigned long cookie)
> >>>   	case DATA_CI_GET:
> >>>   	{
> >>>   		u8 *data = av7110->debi_virt;
> >>> +		u8 data_0 = data[0];
> >>>   
> >>> -		if ((data[0] < 2) && data[2] == 0xff) {
> >>> +		if (data_0 < 2 && data[2] == 0xff) {
> >>>   			int flags = 0;
> >>>   			if (data[5] > 0)
> >>>   				flags |= CA_CI_MODULE_PRESENT;
> >>>   			if (data[5] > 5)
> >>>   				flags |= CA_CI_MODULE_READY;
> >>> -			av7110->ci_slot[data[0]].flags = flags;
> >>> +			av7110->ci_slot[data_0].flags = flags;
> >>
> >> This does not even do what it says. Compiler is still free to access
> >> data[0] multiple times. It needs READ_ONCE() to be effective.
> >
> > Yes, it seems quite dubious to me. If we *really* want to guard against
> > rogue hardware here, the whole DMA buffer should be copied. I don't
> > think it's worth it, a rogue PCI device can do much more harm.
> 
> From the original driver code, data[0] is considered to be bad and thus 
> it should be checked, because the content of the DMA buffer may be 
> problematic.
>
> Based on this consideration, data[0] can be also modified to bypass the 
> check, and thus its value should be copied to a local variable for the 
> check and use.

What makes you think the hardware would do that ?

> I agree with Pavel that the compiler optimization may drop the copying 
> operation, and thus READ_ONCE() should be used here.
> I will submit a v2 patch soon.

-- 
Regards,

Laurent Pinchart