On 07.12.18 18:58, Al Viro wrote: > On Fri, Dec 07, 2018 at 05:10:15PM +0100, Alexander Lochmann wrote: >> >> inode.i_flags might be altered without proper >> synchronisation when the inode belongs to devtmpfs. >> blkdev_write_iter() starts writing via __generic_file_write_iter() >> which sets S_NOSEC bit without any synchronisation. >> The following stacktrace shows how to get there: >> 13: entry_SYSENTER_32:460 >> 12: do_fast_syscall_32:410 >> 11: _static_cpu_has:146 >> 10: do_syscall_32_irqs_on:322 >> 09: SyS_pwrite64:636 >> 08: SYSC_pwrite64:650 >> 07: fdput:38 >> 06: vfs_write:560 >> 05: __vfs_write:512 >> 04: new_sync_write:500 >> 03: blkdev_write_iter:1977 >> 02: __generic_file_write_iter:2897 >> 01: file_remove_privs:1818 >> 00: inode_has_no_xattr:3163 >> If S_NOSEC is *not* set, i_rwsem is acquired around >> __generic_file_write_iter(). > >> + * Ensure excl. access to i_flags in __generic_file_write_iter(). >> + * Otherwise, it would race with chmod adding SUID bit. >> + */ > > _What_ SUID bit? We are talking about a write to block device, for fsck sake... > That's the way I understood Jan's explanation: " Thinking more about this I'm not sure if this is actually the right solution. Because for example the write(2) can set S_NOSEC flag wrongly when it would race with chmod adding SUID bit. So probably we rather need to acquire i_rwsem in blkdev_write_iter() if file does not have S_NOSEC set (we don't want to acquire it unconditionally as that would heavily impact scalability of block device writes). Honza" If I'm mistaking, pls help me with fixing it. - Alex -- Technische Universität Dortmund Alexander Lochmann PGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax: +49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al
Attachment:
signature.asc
Description: OpenPGP digital signature
