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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 3 Aug 2022 16:31:13 +0200 From: Lukas Czerner <lczerner@...hat.com> To: Daniel Ng <danielng@...gle.com> Cc: linux-ext4@...r.kernel.org, Sarthak Kukreti <sarthakkukreti@...gle.com> Subject: Re: [BUG] fsck unable to resolve filenames that include '=' On Tue, Aug 02, 2022 at 06:21:56PM +1000, Daniel Ng wrote: > Hi, > > I've run into an issue when trying to use fsck with an ext4 image when > it has '=' in its name. > > Repro steps: > 1. fallocate -l 1G test=.img > 2. mkfs.ext4 test=.img > 3. fsck test=.img > > Response: > 'fsck.ext4: Unable to resolve '<path>/test=.img' > > Expected: > fsck to do it's thing. > > Observations: > Originally I wasn't sure what the source was, I thought that maybe > mkfs wasn't creating the image appropriately. > However, I've tried: > - renaming the image > - creating a hard-link to the image > > Running fsck on either the renamed image, or the hard-link, works as expected. > > Kernel version: Linux version 4.19.251-13516-ga0bcf8d80077 > Environment: Running on a Chromebook > > Kind regards, > Daniel Hi Daniel, yeah, that's a good catch. The problem is that various e2fsprogs tools (at least tune2fs and e2fsck) are using blkid_get_devname() to get the device name without ever checking if we already got the actual existing device name. The reason to call blkid_get_devname() at all is to get device in the form of NAME=value (like for example UUID=uuid, or LABEL=volume-label). However if we blindly pass in the device (or in this case regular file) name with an equal sign in it, the blkid_get_devname just returns whatever it can find by that tag. Which is likely nothing. Unless of course, you're trying to use e2fsck, or tune2fs on a file with an actual filename LABEL=volume-label and you have actual file system with 'volume-label' LABEL ;) That's a problematic behavior and depending on how we go about fixing it it could be potentialy exploitable... Maybe something like this: 1. look for the actual block device first 2. if none is found call blkid_get_devname() 3. if that didn't return anything maybe see if have a regular file and work with that 4. if we still get nothing, then we're "Unable to resolve..." Thoughts? -Lukas
Powered by blists - more mailing lists