linux-ext4 - Re: ext4: Funny characters appended to file names

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201206151527.GE577125@mit.edu>
Date:   Sun, 6 Dec 2020 10:15:27 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Colin Watson <cjwatson@...ian.org>
Cc:     Paul Menzel <pmenzel@...gen.mpg.de>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        linux-ext4@...r.kernel.org, Dimitri John Ledkov <xnox@...ntu.com>
Subject: Re: ext4: Funny characters appended to file names

On Sun, Dec 06, 2020 at 02:44:16PM +0000, Colin Watson wrote:
> > Colin, the modules in `/boot/grub/i386-pc` look funny, and can’t be loaded
> > by GRUB anymore.
> > 
> > ```
> > $ ls -lt /boot/grub/i386-pc/
> > insgesamt 2085
> > -rw-r--r-- 1 root root    512 13. Aug 23:00 'boot.img-'$'\205\300''u'$'
> > \023\211''鍓]'$'\206\371\377\211\360\350''f'$'\376\377\377\205

I think Colin theory makes sense.  Note the hypthen after "boot.img".
That corresponds with the 'i' in the code below:

> Now that I look at it more closely, some of the changes to
> clean_grub_dir_real look suspicious:
> 
> +         char *srcf = grub_util_path_concat (2, di, de->d_name);
> +
> +         if (mode == CREATE_BACKUP)
> +           {
> +             char *dstf = grub_util_path_concat_ext (2, di, de->d_name, "-");
> +             if (grub_util_rename (srcf, dstf) < 0)
> +               grub_util_error (_("cannot backup `%s': %s"), srcf,
> +                                grub_util_fd_strerror ());
> +             free (dstf);
> +           }

... however, if I'm understanding the code correctly, this is the
codepath used to create the backup file (e.g., the previous version of
boot.img).  So shouldn't there be a "boot.img" file in
/boot/grub/i386-pc which would be the newly installed version of that
file, and so the system would actually be booting correctly?

Or am I misunderstanding what is going on?  Paul, I thought you said
your system wasn't able to boot because the needed files in
/boot/grub/i386-pc had apparently been corrupted?

Essentially, there are three possibilities:

1)  A hardware corruption which corrupted the directory.

2)  A kernel bug which corrupted the directory.

3) The file system isn't actually corrupted, but the filename with the
random garbage in the filename was created because a userspace
application so requested it.

The fact that all of the filenames have the a similar pattern of
corruption to them would tend to rule out #1.  And the fact that
e2fsck didn't notice any other corruptions would tend to argue against
#1 and #2.  So #3 does seem to be the most likely.

       	       	       	       	      	   - Ted