-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: fsconfig(2) does not work with SELinux context options on btrfs #49
Comments
NFS case fixed via 28d4d0e, btrfs remains broken AFAIK. |
FTR, the NFS fix eventually ended up in Linus's tree with ID: 779df6a |
I believe the commit mentioned above fixes a different issue (https://bugzilla.redhat.com/show_bug.cgi?id=1660798). I'm still able to reproduce the NFS |
Maybe fixed by https://lore.kernel.org/selinux/[email protected]/ |
If stack_depot_save_flags() allocates memory it always drops __GFP_NOLOCKDEP flag. So when KASAN tries to track __GFP_NOLOCKDEP allocation we may end up with lockdep splat like bellow: ====================================================== WARNING: possible circular locking dependency detected 6.9.0-rc3+ SELinuxProject#49 Not tainted ------------------------------------------------------ kswapd0/149 is trying to acquire lock: ffff88811346a920 (&xfs_nondir_ilock_class){++++}-{4:4}, at: xfs_reclaim_inode+0x3ac/0x590 [xfs] but task is already holding lock: ffffffff8bb33100 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x5d9/0xad0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> SELinuxProject#1 (fs_reclaim){+.+.}-{0:0}: __lock_acquire+0x7da/0x1030 lock_acquire+0x15d/0x400 fs_reclaim_acquire+0xb5/0x100 prepare_alloc_pages.constprop.0+0xc5/0x230 __alloc_pages+0x12a/0x3f0 alloc_pages_mpol+0x175/0x340 stack_depot_save_flags+0x4c5/0x510 kasan_save_stack+0x30/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x83/0x90 kmem_cache_alloc+0x15e/0x4a0 __alloc_object+0x35/0x370 __create_object+0x22/0x90 __kmalloc_node_track_caller+0x477/0x5b0 krealloc+0x5f/0x110 xfs_iext_insert_raw+0x4b2/0x6e0 [xfs] xfs_iext_insert+0x2e/0x130 [xfs] xfs_iread_bmbt_block+0x1a9/0x4d0 [xfs] xfs_btree_visit_block+0xfb/0x290 [xfs] xfs_btree_visit_blocks+0x215/0x2c0 [xfs] xfs_iread_extents+0x1a2/0x2e0 [xfs] xfs_buffered_write_iomap_begin+0x376/0x10a0 [xfs] iomap_iter+0x1d1/0x2d0 iomap_file_buffered_write+0x120/0x1a0 xfs_file_buffered_write+0x128/0x4b0 [xfs] vfs_write+0x675/0x890 ksys_write+0xc3/0x160 do_syscall_64+0x94/0x170 entry_SYSCALL_64_after_hwframe+0x71/0x79 Always preserve __GFP_NOLOCKDEP to fix this. Link: https://lkml.kernel.org/r/[email protected] Fixes: cd11016 ("mm, kasan: stackdepot implementation. Enable stackdepot for SLAB") Signed-off-by: Andrey Ryabinin <[email protected]> Reported-by: Xiubo Li <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Reported-by: Damien Le Moal <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Suggested-by: Dave Chinner <[email protected]> Tested-by: Xiubo Li <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
As reported in https://lore.kernel.org/selinux/[email protected]/ and https://lore.kernel.org/selinux/[email protected]/, the new fsconfig(2) system call will fail if one attempts to specify one or more of the SELinux context mount option on a nfs or btrfs mount. Both nfs and btrfs make their own calls to the security_sb_set_mnt_opts() LSM hook in addition to the call made from the vfs (fs/super.c:vfs_get_tree). As a result, multiple calls are made to the hook with different options (NULL versus non-NULL), which triggers an error from SELinux due to inconsistent application of security labeling options to a single superblock. It is not clear how to fix this in a manner that still preserves normal nfs and btrfs option handling (aside from dropping the SELinux checks and letting last-call-to-hook "win"). No response from the vfs developers to date. Adding this issue to keep track of this bug until such a time as it gets fixed.
The text was updated successfully, but these errors were encountered: