| 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
| ||
|
Message-ID: <54D2F72B.2040408@redhat.com> Date: Wed, 04 Feb 2015 22:52:59 -0600 From: Eric Sandeen <sandeen@...hat.com> To: Enrico Mioso <mrkiko.rs@...il.com> CC: linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org Subject: Re: Bug in mount options handling in EXT4? On 2/4/15 10:26 PM, Enrico Mioso wrote: > That's fine - as long as we can say that a possibly very very big of "nobarrier" options could be stored some place in memory and cause damage. > Thank you for the reply and attention. > Please - don't remove me from CC as I am not subscribed to any list. > > Enrico Hm, I see now that every "remount" extends the string, that wasn't quite clear from your first email (I thought you simply specified the same option multiple times): > sudo mount -t ext4 -o rw,noatime,nobarrier,nobarrier,nobarrier, ... On my system, remounting with nobarrier a loop eventually fails with: [mntent]: line 13 in /etc/mtab is bad; rest of file ignored mount: can't find mnt in /etc/fstab or /etc/mtab But that's not super graceful. Anyway, this has a bit to do with how util-linux manages /etc/mtab too, I guess. On a system where /etc/mtab links to /proc/mounts, I don't see that behavior. I do think that the length of the string copied from the user during mount (which is what's going on here) is properly sanitized in copy_mount_options(). -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists