linux-kernel - Re: [PATCH AUTOSEL 4.19 08/38] media: pci: ttpci: av7110: fix possible buffer overflow caused by bad DMA value in debiirq()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200829212435.GA9195@gofer.mess.org>
Date:   Sat, 29 Aug 2020 22:24:35 +0100
From:   Sean Young <sean@...s.org>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Pavel Machek <pavel@....cz>, Sasha Levin <sashal@...nel.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Jia-Ju Bai <baijiaju@...nghua.edu.cn>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        linux-media@...r.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()

On Sat, Aug 29, 2020 at 08:16:00PM +0300, 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.

That is a good point. I'm not sure what the kernel could do to protect
against a malicious PCI device (that can do dma) so this patch is totally
pointless.

Thanks

Sean