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-next>] [day] [month] [year] [list]
Date:	Mon, 15 Oct 2007 03:01:57 +0100
From:	Al Viro <viro@....linux.org.uk>
To:	mchehab@...radead.org
Cc:	linux-kernel@...r.kernel.org
Subject: [RFC] vivi, videobuf_to_vmalloc() and related breakage

	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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ