Skip to content
  • Will Deacon's avatar
    fs/9p: avoid accessing utsname after namespace has been torn down · 50192abe
    Will Deacon authored
    During trinity fuzzing in a kvmtool guest, I stumbled across the
    following:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000004
    PC is at v9fs_file_do_lock+0xc8/0x1a0
    LR is at v9fs_file_do_lock+0x48/0x1a0
    [<c01e2ed0>] (v9fs_file_do_lock+0xc8/0x1a0) from [<c0119154>] (locks_remove_flock+0x8c/0x124)
    [<c0119154>] (locks_remove_flock+0x8c/0x124) from [<c00d9bf0>] (__fput+0x58/0x1e4)
    [<c00d9bf0>] (__fput+0x58/0x1e4) from [<c0044340>] (task_work_run+0xac/0xe8)
    [<c0044340>] (task_work_run+0xac/0xe8) from [<c002e36c>] (do_exit+0x6bc/0x8d8)
    [<c002e36c>] (do_exit+0x6bc/0x8d8) from [<c002e674>] (do_group_exit+0x3c/0xb0)
    [<c002e674>] (do_group_exit+0x3c/0xb0) from [<c002e6f8>] (__wake_up_parent+0x0/0x18)
    
    I believe this is due to an attempt to access utsname()->nodename, after
    exit_task_namespaces() has been called, leaving current->nsproxy->uts_ns
    as NULL and causing the above dereference.
    
    A similar issue was fixed for lockd in 9a1b6bf8
    
     ("LOCKD: Don't call
    utsname()->nodename from nlmclnt_setlockargs"), so this patch attempts
    something similar for 9pfs.
    
    Cc: Eric Van Hensbergen <ericvh@gmail.com>
    Cc: Ron Minnich <rminnich@sandia.gov>
    Cc: Latchesar Ionkov <lucho@ionkov.net>
    Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    Signed-off-by: default avatarEric Van Hensbergen <ericvh@gmail.com>
    50192abe