From: "Ma Haijun" <mahaijuns@gmail.com>
To: "'Hans Verkuil'" <hverkuil@xs4all.nl>,
<linux-media@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: "'Mauro Carvalho Chehab'" <m.chehab@samsung.com>,
"'Al Viro'" <viro@ZenIV.linux.org.uk>
Subject: RE: [media] videobuf-dma-contig: fix vm_iomap_memory() call
Date: Sat, 29 Mar 2014 00:58:58 +0800 [thread overview]
Message-ID: <01a501cf4aa7$08664e30$1932ea90$@gmail.com> (raw)
In-Reply-To: <533540CE.8070703@xs4all.nl>
Hi,
> -----Original Message-----
>
> On 03/27/2014 12:07 PM, Ma Haijun wrote:
> > Hi all,
> >
> > This is a trivial fix, but I think the patch itself has problem too.
> > The function requires a phys_addr_t, but we feed it with a dma_handle_t.
> > AFAIK, this implicit conversion does not always work.
> > Can I use virt_to_phys(mem->vaddr) to get the physical address instead?
> > (mem->vaddr and mem->dma_handle are from dma_alloc_coherent)
>
> Does this actually fail? With what driver and on what hardware?
I notice it when I am reading the code,
so I do not know if any driver is broken.
>
> I ask because I am very reluctant to make any changes to videobuf. It is
> slowly being replaced by the vastly superior videobuf2 framework. Existing
> drivers in the kernel still using the old videobuf seem to work just fine
> (or at least as fine as videobuf allows you to be).
Sorry that the cover letter is a bit misleading, hope you does not skip the
patch due to this.
The actual problem is that userland virtual address is erroneously passed to
vm_iomap_memory, while it expects physical address.
And that is what the patch try to address.
Seems this bug can be exploited to map and access physical address.
So it is also a security problem, I think we should ether fix it
or remove the code if not used any more.
Regards,
Haijun
>
> Regards,
>
> Hans
>
> >
> > Regards
> >
> > Ma Haijun
> >
> > Ma Haijun (1):
> > [media] videobuf-dma-contig: fix incorrect argument to
> > vm_iomap_memory() call
> >
> > drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
prev parent reply other threads:[~2014-03-28 16:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-27 11:07 [media] videobuf-dma-contig: fix vm_iomap_memory() call Ma Haijun
2014-03-28 9:28 ` Hans Verkuil
2014-03-28 16:58 ` Ma Haijun [this message]
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='01a501cf4aa7$08664e30$1932ea90$@gmail.com' \
--to=mahaijuns@gmail.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.chehab@samsung.com \
--cc=viro@ZenIV.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.