Skip to content
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.

Sign up for GitHub

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

Jump to bottom

BUG: fsconfig(2) does not work with SELinux context options on btrfs #49

Open
stephensmalley opened this issue Feb 18, 2020 · 4 comments
Open

BUG: fsconfig(2) does not work with SELinux context options on btrfs #49

stephensmalley opened this issue Feb 18, 2020 · 4 comments
Labels
bug priority/medium

Comments

@stephensmalley
Copy link
Member

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.
@stephensmalley
Copy link
Member Author

NFS case fixed via 28d4d0e, btrfs remains broken AFAIK.

@stephensmalley stephensmalley changed the title BUG: fsconfig(2) does not work with SELinux context options on nfs or btrfs BUG: fsconfig(2) does not work with SELinux context options on btrfs Jun 11, 2020
@WOnder93
Copy link
Member

WOnder93 commented Nov 2, 2020

FTR, the NFS fix eventually ended up in Linus's tree with ID: 779df6a

@WOnder93
Copy link
Member

WOnder93 commented Nov 4, 2020

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 fsconfig(2) issue on recent kernels. The NFS version seems to be limited to rootcontext= (possibly others) and, contrary to the original report, I observe the regular mount failing with rootcontext= as well. The NFS and BTRFS bugs seem to have different root causes... I believe I'm close to finding (good) fixes for each of them. Hopefully I'll have some postable patches soon.

@stephensmalley
Copy link
Member Author

Maybe fixed by https://lore.kernel.org/selinux/[email protected]/

stephensmalley pushed a commit to stephensmalley/selinux-kernel that referenced this issue May 2, 2024
@aryabinin @akpm00
stackdepot: respect __GFP_NOLOCKDEP allocation flag
6fe6046 
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug priority/medium
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@WOnder93 @stephensmalley @pcmoore