[PATCH 1/1] *** fix potential NULL dereference in real_cred ***

[Moonlinh]

*** 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)