linux-kernel - Re: regression: 4.13 cannot follow symlinks on some ext3 fs

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]

Message-Id: <700971AC-BDE2-4993-BD56-7497AD8A0FC4@dilger.ca>
Date:   Thu, 23 Nov 2017 17:41:04 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Andi Kleen <andi@...stfloor.org>
Cc:     Theodore Ts'o <tytso@....edu>, tahsin@...gle.com,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: regression: 4.13 cannot follow symlinks on some ext3 fs

On Nov 23, 2017, at 4:31 PM, Andi Kleen <andi@...stfloor.org> wrote:
> 
> On Thu, Nov 23, 2017 at 05:23:17PM -0500, Theodore Ts'o wrote:
>> On Thu, Nov 23, 2017 at 12:33:30PM -0800, Andi Kleen wrote:
>>> 
>>> I have an older qemu VM image that i sometimes use for testing. It
>>> stopped booting with 4.13-4.14 because it couldn't run init.
>>> It uses ext3 for the root file system.
>> 
>> Hmm, do you know roughly when (what krenel version) this image was
>> created?  We had done quite a lot of research and the belief was
>> kernels never would create a "slow" symlink which was less than 60
>> bytes.
> 
> The date of the inode is from 2007, the original kernel was 2.6.17
> with a 32bit kernel.
> 
>> Or was this image something that was created manually (e.g., using debugfs)?
> 
> No, it was installed.

As a workaround, you could delete and recreate the symlink with the new
kernel to create a proper fast symlink.  It would be useful to scan the
image to see if there are other similar symlinks present:

    find /myth/tmp -type l -size -60 -ls | awk '$2 != 0 { print }'

This is probably something that e2fsck should check for and fix.

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)