linux-kernel - vfat creates multiple files with the same filename

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

Date:	Sun, 28 Jun 2009 20:26:09 +0200 (CEST)
From:	Marton Balint <cus@...ekas.hu>
To:	linux-kernel@...r.kernel.org
cc:	hirofumi@...l.parknet.co.jp
Subject: vfat creates multiple files with the same filename

Hi, 

If I use vfat with the utf8 mount option, and create a file with an 
invalid utf-8 character in it's name, then the invalid charater gets 
removed from the filename silently. That's probably the expected way of 
operation but the problem is, that this automatic filename sanitization 
can be used to create multiple files with the same filename. Here's an 
example how to do it:

mkdir /mnt/fatfs
FILENAME=`echo -ne "invalidutf8char_\\0341_endofchar"`
echo "Using filename: $FILENAME"
dd if=/dev/zero of=fatfs bs=512 count=128
mkdosfs -F 32 fatfs
mount -o loop,utf8 fatfs /mnt/fatfs
touch "/mnt/fatfs/$FILENAME"
umount /mnt/fatfs
mount -o loop,utf8 fatfs /mnt/fatfs
touch "/mnt/fatfs/$FILENAME"
ls -l /mnt/fatfs
umount /mnt/fatfs

----  And the output is:

Using filename: invalidutf8char_á_endofchar
128+0 records in
128+0 records out
65536 bytes (66 kB) copied, 0.000388118 s, 169 MB/s
mkdosfs 2.11 (12 Mar 2005)
total 0
-rwxr-xr-x 1 root root 0 Jun 28 19:46 invalidutf8char__endofchar
-rwxr-xr-x 1 root root 0 Jun 28 19:46 invalidutf8char__endofchar

I don't know if removing the invalid characters silently instead of 
returning EINVAL is a good practice, but allowing two files with identical 
filenames is definitely wrong. 

Could someone please have a look at the problem? Unfortunately I am not 
qualified enough to track it down...

I've run the testcase on both 2.6.30 and 2.6.31-rc1 kernels, but this bug 
is probably not very new, since I remember having it also in 2.6.27.

Regards,
  Marton