From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qn8eX-0000AT-Hx for qemu-devel@nongnu.org; Sat, 30 Jul 2011 08:28:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qn8eW-0003uf-FN for qemu-devel@nongnu.org; Sat, 30 Jul 2011 08:28:25 -0400 Received: from busoni.debian.org ([140.211.15.34]:34458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qn8eW-0003tO-Az for qemu-devel@nongnu.org; Sat, 30 Jul 2011 08:28:24 -0400 Resent-To: debian-bugs-dist@lists.debian.org Resent-Message-ID: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Johannes Schauer Message-ID: <20110730122434.25086.45185.reportbug@hoothoot> Date: Sat, 30 Jul 2011 14:24:34 +0200 Sender: j.schauer@email.de Subject: [Qemu-devel] Bug#636035: qemu-user: init_paths() doesnt guard against recursive link cycles Reply-To: Johannes Schauer , 636035@bugs.debian.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Debian Bug Tracking System Package: qemu-user Version: 0.14.1+dfsg-3 Severity: normal Hi, when a symbolic or hardlink which creates a recursive cycle exists in the directory specified as the elf interpreter prefix (default=/etc/qemu-binfmt//), qemu-user will recursively traverse this path and never finish (eating tons of memory in the process). The easiest way to reproduce is to do: ln -s '.' /etc/qemu-binfmt//foobar (or wherever directory you pointed qemu to with the -L option) This is mostly annoying because there exists the /usr/bin/X11 symlink which points to '.' in debian systems with x11-common installed. Other problems occur with /proc/self/fd/ (and /dev/fd/ which links to it) when /proc is mounted in the elf interpreter prefix path. The problem occurs when init_paths() is called on interp_prefix (the elf interpreter prefix path). init_paths() doesnt protect from infinitely traversing cyclic symlinks. find(1) solves this problem by maintaining a hashtable of (to be) traversed directories and skipping directories that are found to be already part of it. I can prepare a patch for path.c (which defines init_paths()) which guards against this behaviour in the same way that find(1) does if this problem is desired to be solved that way. cheers, josch