From: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: mchehab@kernel.org, kstewart@linuxfoundation.org,
tomasbortoli@gmail.com, sean@mess.org, allison@lohutok.net,
tglx@linutronix.de, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] media: usb: ttusb-dec: avoid buffer overflow in ttusb_dec_handle_irq() when DMA failures/attacks occur
Date: Thu, 7 May 2020 13:15:22 +0800 [thread overview]
Message-ID: <4bc70ec6-e518-5f42-b336-c86e1f92619f@gmail.com> (raw)
In-Reply-To: <20200506174345.GA3711921@kroah.com>
On 2020/5/7 1:43, Greg KH wrote:
> On Thu, May 07, 2020 at 12:48:47AM +0800, Jia-Ju Bai wrote:
>> Yes, I agree that this issue is not new, because DMA attacks are old
>> problems.
>> But I am a little surprised that many current drivers are still vulnerable
>> to DMA attacks.
> Given that the attack vector is very hard to actually do, that's not
> a suprise.
>
> It's only a very recent thing that Linux drivers have started to work on
> "we don't trust the data coming from the hardware" path. Previously we
> always trusted that, but did not trust data coming from userspace. So
> work on fixing up drivers in this area is always encouraged.
>
> An example of this would be all of the fuzzing that USB drivers have
> been getting with custom loop-back interfaces and the like over the past
> year or so. Expanding that to "we don't trust PCI device data" should
> be the next step on this, and would help out your area as well.
Okay, I am glad to hear that :)
Hardware security for the Linux kernel should receive more attention.
Last year some researchers finished an interesting work about fuzzing
the inputs from hardware:
https://github.com/securesystemslab/periscope
>
>>> If you trust a device enough to plug it in, well, you need to trust it
>>> :)
>> Well, maybe I need to trust all devices in my computer :)
>>
>> Anyway, thanks a lot for your patient explanation and reply.
>> If you have encountered other kinds of DMA-related bugs/vulnerabilities,
>> maybe I can help to detect them using my static-analysis tool :)
> Did you only find a problem in this one driver? Have you run it on any
> more "complex" drivers and gotten any good results showing either that
> we are programming defensively in this area, or not?
>
At present, I only detect the cases that a DMA value *directly* taints
array index, loop condition and important kernel-interface calls (such
as request_irq()).
In this one driver, I only find two problems that mentioned in this patch.
With the kernel configuration "allyesconfig" in my x86_64 machine, I
find nearly 200 such problems (intra-procedurally and
inter-procedurally) in all the compiled device drivers.
I also find that several drivers check the data from DMA memory, but
some of these checks can be bypassed.
Here is an example in drivers/scsi/esas2r/esas2r_vda.c:
The function esas2r_read_vda() uses a DMA value "vi":
struct atto_ioctl_vda *vi =
(struct atto_ioctl_vda *)a->vda_buffer;
Then esas2r_read_vda() calls esas2r_process_vda_ioctl() with vi:
esas2r_process_vda_ioctl(a, vi, rq, &sgc);
In esas2r_process_vda_ioctl(), the DMA value "vi->function" is
used at many places, such as:
if (vi->function >= vercnt)
...
if (vi->version > esas2r_vdaioctl_versions[vi->function])
...
However, when DMA failures or attacks occur, the value of vi->function
can be changed at any time. In this case, vi->function can be first
smaller than vercnt, and then it can be larger than vercnt when it is
used as the array index of esas2r_vdaioctl_versions, causing a
buffer-overflow vulnerability.
I also submitted this patch, but no one has replied yet:
https://lore.kernel.org/lkml/20200504172412.25985-1-baijiaju1990@gmail.com/
Best wishes,
Jia-Ju Bai
next prev parent reply other threads:[~2020-05-07 5:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-05 14:21 [PATCH] media: usb: ttusb-dec: avoid buffer overflow in ttusb_dec_handle_irq() when DMA failures/attacks occur Jia-Ju Bai
2020-05-05 18:10 ` Greg KH
2020-05-06 10:13 ` Jia-Ju Bai
2020-05-06 11:07 ` Greg KH
2020-05-06 15:30 ` Jia-Ju Bai
2020-05-06 15:52 ` Greg KH
2020-05-06 16:48 ` Jia-Ju Bai
2020-05-06 17:43 ` Greg KH
2020-05-07 5:15 ` Jia-Ju Bai [this message]
2020-05-07 7:52 ` Greg KH
2020-05-07 9:59 ` Jia-Ju Bai
2020-05-07 8:43 ` Sean Young
2020-05-07 10:11 ` Jia-Ju Bai
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=4bc70ec6-e518-5f42-b336-c86e1f92619f@gmail.com \
--to=baijiaju1990@gmail.com \
--cc=allison@lohutok.net \
--cc=gregkh@linuxfoundation.org \
--cc=kstewart@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=sean@mess.org \
--cc=tglx@linutronix.de \
--cc=tomasbortoli@gmail.com \
/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).