suspicious RCU usage from smack code

[Casey Schaufler]

On 2/25/2020 9:59 AM, John Garry wrote:
> Hi guys,
>
> JFYI, When I enable CONFIG_PROVE_RCU=y, I get these:
>
> [    0.369697] WARNING: suspicious RCU usage
> [    0.374179] 5.6.0-rc3-00002-g619882231229-dirty #1753 Not tainted
> [    0.380974] -----------------------------
> [    0.385455] security/smack/smack_lsm.c:354 RCU-list traversed in non-reader section!!
> [    0.394183]
> [    0.394183] other info that might help us debug this:
> [    0.394183]
> [    0.403107]
> [    0.403107] rcu_scheduler_active = 1, debug_locks = 1
> [    0.410389] no locks held by kthreadd/2.
> [    0.414770]
> [    0.414770] stack backtrace:
> [    0.419636] CPU: 0 PID: 2 Comm: kthreadd Not tainted 5.6.0-rc3-00002-g619882231229-dirty #1753
> [    0.429204] Call trace:
> [    0.431924]  dump_backtrace+0x0/0x298
> [    0.435990]  show_stack+0x14/0x20
> [    0.439674]  dump_stack+0x118/0x190
> [    0.443548]  lockdep_rcu_suspicious+0xe0/0x120
> [    0.448487]  smack_cred_prepare+0x2f8/0x310
> [    0.453134]  security_prepare_creds+0x64/0xe0
> [    0.457979]  prepare_creds+0x25c/0x368
> [    0.462141]  copy_creds+0x40/0x620
> [    0.465918]  copy_process+0x62c/0x25e0
> [    0.470084]  _do_fork+0xc0/0x998
> [    0.473667]  kernel_thread+0xa0/0xc8
> [    0.477640]  kthreadd+0x2b0/0x408
> [    0.481325]  ret_from_fork+0x10/0x18
>
> [   18.804382] =============================
> [   18.808872] WARNING: suspicious RCU usage
> [   18.813348] 5.6.0-rc3-00002-g619882231229-dirty #1753 Not tainted
> [   18.820145] -----------------------------
> [   18.824621] security/smack/smack_access.c:87 RCU-list traversed in non-reader section!!
> [   18.833544]
> [   18.833544] other info that might help us debug this:
> [   18.833544]
> [   18.842465]
> [   18.842465] rcu_scheduler_active = 1, debug_locks = 1
> [   18.849741] no locks held by kdevtmpfs/781.
> [   18.854410]
> [   18.854410] stack backtrace:
> [   18.859277] CPU: 1 PID: 781 Comm: kdevtmpfs Not tainted 5.6.0-rc3-00002-g619882231229-dirty #1753
> [   18.869138] Call trace:
> [   18.871860]  dump_backtrace+0x0/0x298
> [   18.875929]  show_stack+0x14/0x20
> [   18.879612]  dump_stack+0x118/0x190
> [   18.883489]  lockdep_rcu_suspicious+0xe0/0x120
> [   18.888428]  smk_access_entry+0x110/0x128
> [   18.892885]  smk_tskacc+0x70/0xe8
> [   18.896568]  smk_curacc+0x64/0x78
> [   18.900249]  smack_inode_permission+0x110/0x1c8
> [   18.905284]  security_inode_permission+0x50/0x98
> [   18.910412]  inode_permission+0x70/0x1d0
> [   18.914768]  link_path_walk.part.38+0x4a8/0x778
> [   18.919802]  path_lookupat+0xd0/0x1a8
> [   18.923871]  filename_lookup+0xf0/0x1f8
> [   18.928136]  user_path_at_empty+0x48/0x58
> [   18.932590]  ksys_chdir+0x8c/0x138
> [   18.936366]  devtmpfsd+0x148/0x448
> [   18.940146]  kthread+0x1c8/0x1d0
> [   18.943732]  ret_from_fork+0x10/0x18
>
> I haven't had a chance to check whether they are bogus or not.

This is the case where a process with local rules is forked,
requiring that a copy of its rules be made for the child. The
local rules are not used in any production environment that I
know of. It was done for MeeGo. The local rule list really ought
to get moved from the cred to the task blob, now that we have one.

If this turns out to be real it's unlikely to cause any harm as
no one is using local rules. The real fix would take take it out
of the cred blob, and that's a significant change. The RCU details
should be reviewed at that time.

Unless this is worse than it looks.

>
> Thanks,
> John