linux-kernel - Re: KVM overflows the stack

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]

Date:	Thu, 17 Jul 2008 07:06:01 -0700
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	Roland Dreier <rdreier@...co.com>
Cc:	Avi Kivity <avi@...ranet.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	kvm-devel <kvm@...r.kernel.org>,
	"Anthony N. Liguori [imap]" <aliguori@...ibm.com>
Subject: Re: KVM overflows the stack

On Wed, 2008-07-16 at 23:08 -0700, Roland Dreier wrote:
>  > Yes, things like kvm_lapic_state are way too big to be on the
> stack.
> 
> I had a quick look at the code, and my worry about dynamic allocation
> would be that handling allocation failure seems like it might get
> tricky.  Eg for handling struct kvm_pv_mmu_op_buffer (which is 528 bytes
> on the stack in kvm_pv_mmu_op()) can you deal with an mmu op failing?

Well, you *better* be able to deal with it.  :)

This code is also doing a *ton* of copy_to/from_user().  If userspace
had one of its input buffers swapped out (or one of its output buffers
not faulted in yet) and we're out of memory enough to be failing
kmallocs() then we're sure as heck also going to failing the user
copies.

I think it's a non-issue.

-- Dave

--
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/