Your message dated Thu, 5 Apr 2018 23:18:03 +0300
with message-id <[email protected]>
and subject line Re: Bug#636035: qemu-user: init_paths() doesnt guard against
recursive link cycles
has caused the Debian Bug report #636035,
regarding qemu-user: init_paths() doesnt guard against recursive link cycles
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
636035: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636035
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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/<arch>/), 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/<arch>/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
--- End Message ---
--- Begin Message ---
Version: 1.1.2+dfsg-6a
This has been fixed meanwhile. Current version treats ELOOP as
an indicator to stop, and everything works fine.
When it has been fixed - I don't know. Marking as fixed in wheezy.
Thanks,
/mjt
--- End Message ---
