From: Al Viro <viro@ftp.linux.org.uk>
To: mchehab@infradead.org
Cc: linux-kernel@vger.kernel.org
Subject: [RFC] vivi, videobuf_to_vmalloc() and related breakage
Date: Mon, 15 Oct 2007 03:01:57 +0100 [thread overview]
Message-ID: <20071015020157.GC8181@ftp.linux.org.uk> (raw)
AFAICS, videobuf-vmalloc use of mem->vma and mem->vmalloc is
bogus.
You obtain the latter with vmalloc_user(); so far, so good. Then you have
retval=remap_vmalloc_range(vma, mem->vmalloc,0);
where vma is given to you by mmap(); again, fine - we get the memory
pointed to be mem->vmalloc() mapped at vma->vm_start.
Now we get the trouble: things like
static void vivi_fillbuff(struct vivi_dev *dev,struct vivi_buffer *buf)
{
...
void *vbuf=videobuf_to_vmalloc (&buf->vb);
...
copy_to_user(vbuf + ..., ..., ...)
get vbuf equal to ->vmalloc of buf->vp.priv and that is _not_ a userland
address. Giving it to copy_to_user() is not going to do anything good.
On some targets it'll fail, on some - write to unrelated user memory.
What is going on there? If that's an attempt to copy into that buffer
allocated by vmalloc_user(), why are we doing copy_to_user() at all?
But there's more; we have made a copy of vma (kmalloc+memcpy), stored it in
mem->vma and later we cheerfully do remap_vmalloc_range(mem->vma,....).
And kfree that mem->vma immediately afterwards. What the hell? It might
not break now, but that seems to be playing very fast and loose with the
warranties provided by VM.
next reply other threads:[~2007-10-15 2:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-15 2:01 Al Viro [this message]
2007-10-15 7:59 ` [RFC] vivi, videobuf_to_vmalloc() and related breakage Nick Piggin
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=20071015020157.GC8181@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@infradead.org \
/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.