linux-kernel - Re: [PATCH] amd_iommu: Fix leak in free

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] [day] [month] [year] [list]

Message-ID: <20130620200406.GE11309@8bytes.org>
Date:	Thu, 20 Jun 2013 22:04:06 +0200
From:	Joerg Roedel <joro@...tes.org>
To:	Alex Williamson <alex.williamson@...hat.com>
Cc:	iommu@...ts.linux-foundation.org, ddutile@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] amd_iommu: Fix leak in free_pagetable()

On Thu, Jun 20, 2013 at 01:46:48PM -0600, Alex Williamson wrote:
> But that's true of a bug in any kernel code.  I think the only danger
> unique to recursion is using too much stack space, but I doubt that's
> really an issue for a tiny function with a fixed depth like this.  In
> case you didn't notice, I did send a recursive version along with the
> flat version, but I stupidly used the same subject for both.  It's a
> little less code and a tiny bit easier to understand than the macro
> version.  Up to you though.

Well, the limited kernel stack is exactly the problem for an
unterminating recursion. The size of the stack-footprint does also not
really matter in this situation, the code will overwrite random kernel
memory when the stack overflows. And that memory could potentially
contain data that is about to be written to disk and destroy file
systems.


	Joerg

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