From: ChenJinhao <chen.jinhao@xxxxxxxxxx>
When PAUSE-Loop-Exiting is triggered, it is possible that task->real_cred
will be set to NULL. In this case, directly parsing euid and egid of real_cred in
task_dump_owner will lead to NULL dereference and cause kernel panic like below.
#1 [ffff97eb73757938] __crash_kexec at ffffffff8655bbdd
#2 [ffff97eb73757a00] crash_kexec at ffffffff8655cabd
#3 [ffff97eb73757a18] oops_end at ffffffff86421edd
#4 [ffff97eb73757a38] no_context at ffffffff8646978e
#5 [ffff97eb73757a90] do_page_fault at ffffffff8646a2c2
#6 [ffff97eb73757ac0] page_fault at ffffffff86e0120e
[exception RIP: task_dump_owner+47]
RIP: ffffffff867496cf RSP: ffff97eb73757b78 RFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff89fbb63dbd80 RCX: ffff89bb687677c0
RDX: ffff89bb687677bc RSI: 000000000000416d RDI: ffff89fbb63dbd80
RBP: 0000000000000000 R8: ffff89f51e1f5980 R9: 732f373839323734
R10: 0000000000000006 R11: 0000000000000000 R12: ffff89bb687677c0
R13: ffff97eb73757c50 R14: ffff89f53b19c7a0 R15: ffff8a75170e2cc0
euid and egid are temporarily set here, and for certain modes, they will
be updated to GLOBAL_ROOT_UID/GID by default when make_uid/make_gid
returns invalid values.
So, whether the NULL real_cred can also be considered as invalid value, and
treat the same?
---
fs/proc/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 9e479d7d202b..2cb77fc64e28 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1833,8 +1833,8 @@ void task_dump_owner(struct task_struct *task, umode_t mode,
/* Default to the tasks effective ownership */
rcu_read_lock();
cred = __task_cred(task);
- uid = cred->euid;
- gid = cred->egid;
+ uid = cred == NULL ? GLOBAL_ROOT_UID : cred->euid;
+ gid = cred == NULL ? GLOBAL_ROOT_GID : cred->egid;
rcu_read_unlock();
/*
--
2.24.3 (Apple Git-128)
