Not sure if "process management" is the right place to report this, but 
there's a null pointer dereference on kernel/auditsc.c as follows:

(1) assume the condition on line 1995 is true
(2) assume the condition on line 1996 is also true
(3) assume the test "if (ctxt)" at line 1998 evaluates to
    false, which implies that "ctx" is null
(4) assume that the condition at line 2004 is false so
    that we don't return
(5) then the expression "if (!ctx->target_pid)" (line 2010)
    is executed with a "ctx" pointer that's null.

This is a false alarm only if "ctx" is never null. But then the test
"if (ctx)" at line 1998 is bogus (which means some code change is
needed).

Your line numbers don't match up with any kernel I can find so I'm going ENTIRELY on where I see if(!ctx->target_pid) which is inside __audit_signal_info().  Assuming I'm looking at the right function you are right about there being needless extra checks for if(ctx) because the only caller to __audit_signal_info is:

kernel/audit.h::audit_signal_info()

which includes a check for !audit_dummy_context() which really does nothing but check if current has a valid audit_context.

since we can never get into __audit_signal_info with current->audit_context == NULL all of the checks inside for NULL are needless and a waste of time, but this doesn't appear to be a NULL pointer dereference to me.

(In reply to comment #2)
> Your line numbers don't match up with any kernel I can find so I'm going
> ENTIRELY on where I see if(!ctx->target_pid) which is inside
> __audit_signal_info().  Assuming I'm looking at the right function you are
> right about there being needless extra checks for if(ctx) because the only
> caller to __audit_signal_info is:
> 
Given 2.6.23, this was an accurate bug report. It was fixed by Al Viro in bfef93a5d1fb5654fe2025276c55e202d10b5255, in the 2.6.25-rc1 cycle.