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-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250818174911.365889-1-ethan.ferguson@zetier.com>
Date: Mon, 18 Aug 2025 13:49:11 -0400
From: Ethan Ferguson <ethan.ferguson@...ier.com>
To: hch@...radead.org
Cc: ethan.ferguson@...ier.com,
	linkinjeon@...nel.org,
	linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	sj1557.seo@...sung.com,
	yuezhang.mo@...y.com
Subject: [PATCH v2 0/1] exfat: Add support for FS_IOC_{GET,SET}FSLABEL

On 8/18/25 01:52, Christoph Hellwig wrote:
> On Sun, Aug 17, 2025 at 10:32:00AM -0400, Ethan Ferguson wrote:
>> Both e2fsprogs and btrfs-progs now use the FS_IOC_{GET,SET}FSLABEL
>> ioctls to change the label on a mounted filesystem.
> 
> Additionally userspace writes to blocks on mounted file systems are
> dangerous.  They can easily corrupt data when racing with updates
> performed by the kernel, and are impossible when the the
> CONFIG_BLK_DEV_WRITE_MOUNTED config option is disabled.

That's fair. I took a look at how btrfs guards against this, it seems
as if they use mnt_want_write_file to guard against bad writes, and
only write to the in-memory superblock, and commit the transaction
afterwards. However, this (during my testing with
CONFIG_BLK_DEV_WRITE_MOUNTED both on and off) still results in an
immediate disk flush.

My changes from this thread also seem to work with
CONFIG_BLK_DEV_WRITE_MOUNTED both disabled and enabled.

Maybe an alternative would be to only write to sbi->volume_label (with
mutex guarding), and only flush to disk on exfat_put_super? And to use
mnt_want_write_file as well.

Unfortunately, given that I'm pretty new to kernel development, I
wouldn't know that the best way to approach this. Any thoughts, or
pointers in the right direction, would be appreciated.

Thank you for the feedback!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ