GNOME Bugzilla – Bug 762448
Check FAT32 fs crashes GParted
Last modified: 2020-11-15 15:33:33 UTC
Created attachment 321831 [details] Crash log Gparted 0.19.0 Hi, I've got a FAT32 fs which I believe contains an infinite directory loop. This loop was created by Cyanogen Filemanager 3.0.0 (CM-12.1) when I tried to rename "folder" to "Folder". Whenever I try to check the FS, Gparted crashes. fsck.fat 3.0.28 does not complain at all, and does not repair anything. Did I use wrong fsck arguments? Any suggestion? The attached log is from my Kubuntu installation, gparted 0.19.0. I also tried it from gparted-live-0.25.0-3-i686.iso Same result, but difficult to fetch log. btw, where do I find the core dump? thanks
Hi, If I understand you setup correctly, you have an Android device (phone, tablet of something else) running CyanogenMod. In such a case I expect that the file system driver is part of the Linux kernel, and the file manager merely requested the folder to be renamed. I assume Cyanogen Filemanager is running directly on the Android device with the FAT32 file system in question. ====================== libparted : 3.2 ====================== *** buffer overflow detected ***: /usr/sbin/gpartedbin terminated ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x78c4e)[0x7f73d37a5c4e] /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f73d3845e8c] /lib/x86_64-linux-gnu/libc.so.6(+0x116e80)[0x7f73d3843e80] /lib/x86_64-linux-gnu/libparted-fs-resize.so.0(+0x42a2)[0x7f73d67802a2] /lib/x86_64-linux-gnu/libparted-fs-resize.so.0(+0x435b)[0x7f73d678035b] /lib/x86_64-linux-gnu/libparted-fs-resize.so.0(+0x435b)[0x7f73d678035b] /lib/x86_64-linux-gnu/libparted-fs-resize.so.0(+0x435b)[0x7f73d678035b] /lib/x86_64-linux-gnu/libparted-fs-resize.so.0(+0x435b)[0x7f73d678035b] ... Looking at this fragment of the log it suggests that GParted crashed in the GNU Parted (http://www.gnu.org/software/parted/) library: libparted-fs-resize.so. Q: Did you use the wrong fsck arguments? A: GParted run this command: fsck.fat -a -w -v /dev/PTN Also note that as part of a check operation GParted tries to resize a file system to fill the partition. This is where I suspect the crash is happening. Q: Where do I find the core dump? A: Most distros write core dumps to automatic bug reporting tools and suppress writing of core dumps to the local disk. Q: Any suggestions? A: Generate a core dump on your Kubuntu installation following the instructions below. Thanks, Mike How to capture a backtrace from a coredump ------------------------------------------ 1) Turn off any OS core dump capturing, ensuring: cat /proc/sys/kernel/core_pattern reports just "core" Some methods to do this, depending on distro version, are: * service abrt-ccpp stop * systemctl stop abrtd * sudo service apport stop 2) Increase core dump limit and run GParted as root Either: ulimit -c unlimited sudo gparted or: su - root ulimit -c unlimited gparted 3) Perform crashing action 4) Capture backtrace ls -lrt core* which gpartedbin gdb `which gpartedbin` {COREFILE} --batch --quiet \ -ex backtrace -ex quit > backtrace.log Please paste the terminal output when running gparted and the contents of the backtrace.log file.
Ok. I did the following: echo core > /proc/sys/kernel/core_pattern $ sudo kpartx -av sample.img add map loop0p1 (252:0): 0 62325760 linear /dev/loop0 8192 $ ln -s /dev/mapper/loop0p1 sample.img1 $ sudo gparted sample.img $ ls -lrt core* -rw------- 1 root root 33820672 Feb 23 13:56 core $ which gpartedbin /usr/sbin/gpartedbin $ chown jan:jan core $ gdb `which gpartedbin` core --batch --quiet -ex backtrace -ex quit > backtrace.log It complains: 55 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. Do I need the sources? of what exactly? And I created a disk image which crashes gparted. I's size 100 MB, compressed 17k I created it by copying the cyclic dir from my original disk. ln doesn't want to link dirs.
Created attachment 321955 [details] disk image which crashes gparted you can "mount" this in gparted if you create a loopback device like this: $ sudo kpartx -av test.img add map loop0p1 (252:0): 0 62325760 linear /dev/loop0 8192 $ ln -s /dev/mapper/loop0p1 test.img1
Created attachment 321956 [details] backtrace
Your assumptions regarding the smart phone are correct. And yes if I think about it, it should be a kernel problem. Phone Kernel is version 3.4.0. I believe it is heavily modified though... My PC's kernel simply copied the cyclic directory over, so stock Ubuntu kernel handles cyclic dirs on FAT a bit too relaxed? Linux TUX 4.2.0-27-generic #32-Ubuntu SMP x86_64 I believe ext2 actually allows cyclic dirs?
Thank you for the file system image, I have reproduced the crash of GParted. Backtrace below. It's crashing in function flag_tracerse_dir() in library libparted-fs-resize. The function recursively traverses the directory structure so it's definitely not expecting a infinitely deep directory structure from a directory hard linked to itself. In fact I suspect most every tool expects the depth of the directory tree to be limited. Note that it is not possible to create hard linked directories on the Linux command line on any file system because ln refuses. # fgrep /mnt/2 /proc/self/mounts /dev/md127p2 /mnt/2 ext2 rw,seclabel,relatime,errors=continue 0 0 # cd /mnt/2 # mkdir a # ln a b ln: `a': hard link not allowed for directory Android Linux 3.4.0, CyanogenMod 12.1 and Filemanager 3.0.0 definitely should not be allowing a directory to be hard linked to itself. You'll need to report that to Cyanogen. In the mean time I'll try to make libparted immune. Thanks, Mike # ./gpartedbin /dev/loop0 ====================== libparted : 2.4 ====================== *** buffer overflow detected ***: ./gpartedbin terminated ... # gdb ./gpartedbin core.11167 --batch --quiet -ex backtrace -ex quit [New Thread 11167] [New Thread 11170] [Thread debugging using libthread_db enabled] Core was generated by `./gpartedbin /dev/loop0'. Program terminated with signal 6, Aborted.
+ Trace 235990
Note that the Linux link(2) system call also prevent creating hard links to directories. # cat t.c #include <unistd.h> #include <sys/stat.h> int main(void) { mkdir("a", 0755); link("a", "a/a"); return 0; } # gcc -o t t.c # fgrep /mnt /proc/self/mounts /dev/sdb2 /mnt/2 ext4 rw,seclabel,relatime,data=ordered 0 0 /dev/sdc4 /mnt/4 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 0 # cd /mnt/2 # strace ~/t ... mkdir("a", 0755) = 0 link("a", "a/a") = -1 EPERM (Operation not permitted) # cd /mnt/4 # strace ~/t ... mkdir("a", 0755) = 0 link("a", "a/a") = -1 EPERM (Operation not permitted) The manal page for link(2) says that trying to create a hard link to a directory is not allowed and will fail with EPERM error. http://man7.org/linux/man-pages/man2/link.2.html int link(const char *oldpath, const char *newpath); ... ERRORS ... EPERM oldpath is a directory. So either Android Linux is broken or CyanogenMod / Filemanager is totally bypassing the the Linux kernel VFS and file system driver and modifying the file system directly itself and is broken.
I have examined the file system image from comment #3 a bit closer. The directory "keepass" is not hard linked to itself. Instead it is a very deep directory structure. If I can count properly, it is 453 "keepass" directories deep, with a relative path length of 3623 characters. It might well be that there is an infinite loop is CyanogenMod Filemanager and it stopped when it reached some path limit.
I've submitted a parted patchset to resolve this bug. [PATCH 0/2] Prevent crash resizing FAT with very deep directories http://lists.alioth.debian.org/pipermail/parted-devel/2016-February/004800.html
Cool. Thank you very much for dealing with my bug report so quickly. This way reporting bugs is fun :) I checked the orig image. It's 453 dirs deep too. This explains why the app took so long to fail. And it is a strong hint the bug is located in the app, not the kernel.
Patches were applied to the parted GIT repository: lib-fs-resize: Prevent crash resizing FAT with very deep directories http://git.savannah.gnu.org/cgit/parted.git/commit/?id=6242ad71d855be62d99ec345e52393be86ca9900 tests: t3000-resize-fs.sh: Add very deep directory http://git.savannah.gnu.org/cgit/parted.git/commit/?id=27b57de66c7560945cf87e5287911975939225ec Curtis, As parted don't release very often we should make sure that the next GParted Live CD includes the patches even if Debian don't pick it up. Thanks, Mike
A custom version of libparted which includes these patches was included in GParted Live 0.26.0-1.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use gparted and if you still see this bug / want this feature in a recent and currently supported version, then please feel free to report it at https://gitlab.gnome.org/GNOME/gparted/-/issues/ by following the guidelines at https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines Thank you for creating this report and we are sorry it could not be implemented so far (volunteer workforce and time is limited).
Parted v3.3 was released 2019-10-10 which includes the commits mentioned in comment #11. http://git.savannah.gnu.org/cgit/parted.git/commit/?h=v3.3&id=d6594b56a8d8e74185e11608f1b61471af7cc114 https://ftp.gnu.org/gnu/parted/