*** BLURB HERE *** ChenJinhao (1): fix NULL dereference in real_cred 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(-) -- 2.24.3 (Apple Git-128)