Project

General

Profile

Bug #12593

NULL ptr deref in door_upcall via auditctl setpolicy

Added by Alex Wilson 3 months ago. Updated 22 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

We had a bunch of systems panic with this stack:

panic message: BAD TRAP: type=e (#pf Page fault) rp=fffffe017e64eb30 addr=28 occurred in module "doorfs" due to a NULL pointer dereference
dump content: kernel pages only
> $C
fffffe017e64ecc0 door_upcall+0x39(0, fffffe017e64ece0, 0, ffffffffffffffff, 0)
fffffe017e64ed50 au_door_upcall+0x95(ffffff0a222af300, ffffff0cfbe78290)
fffffe017e64edb0 au_doormsg+0x8b(ffffff0a222af300, 1, fffffe017e64edcc)
fffffe017e64edf0 setpolicy+0xa7(8047cdc)
fffffe017e64ee40 auditctl+0xc0(3, 8047cdc, 0)
fffffe017e64ee70 auditsys+0xd1(ffffff0bb659bbf8, fffffe017e64ee80)
fffffe017e64eeb0 syscall_ap+0x8e()
fffffe017e64ef10 _sys_sysenter_post_swapgs+0x159()

In setpolicy() we have a check on kctx->auk_current_vp != NULL before we call au_doormsg, but we're not holding the lock which protects this member at the time (auk_svc_lock). When we later grab that lock (in au_door_upcall) we don't double-check the state of auk_current_vp, but instead pass it directly to door_upcall which derefs it blindly. So we have a TOCTOU race.

We should probably at least double-check it isn't NULL before we give it to door_upcall

History

#1

Updated by Joshua M. Clulow 22 days ago

  • Gerrit CR set to 576

Also available in: Atom PDF