[PATCH 1/1] fix NULL dereference in real_cred

[Moonlinh]

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)