summaryrefslogtreecommitdiff
path: root/net/xfrm/xfrm_replay.c
diff options
context:
space:
mode:
authorTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>2014-04-18 11:23:46 +0400
committerSteffen Klassert <steffen.klassert@secunet.com>2014-04-22 12:47:53 +0400
commitf1370cc4a01e61007ab3020c761cef6b88ae3729 (patch)
treebee103f4c6398b978b47b1b6bba8e097c1e332aa /net/xfrm/xfrm_replay.c
parent5a9d19ab76f98b7cdc97ba9724be01deba791bc0 (diff)
downloadlinux-f1370cc4a01e61007ab3020c761cef6b88ae3729.tar.xz
xfrm: Remove useless secid field from xfrm_audit.
It seems to me that commit ab5f5e8b "[XFRM]: xfrm audit calls" is doing something strange at xfrm_audit_helper_usrinfo(). If secid != 0 && security_secid_to_secctx(secid) != 0, the caller calls audit_log_task_context() which basically does secid != 0 && security_secid_to_secctx(secid) == 0 case except that secid is obtained from current thread's context. Oh, what happens if secid passed to xfrm_audit_helper_usrinfo() was obtained from other thread's context? It might audit current thread's context rather than other thread's context if security_secid_to_secctx() in xfrm_audit_helper_usrinfo() failed for some reason. Then, are all the caller of xfrm_audit_helper_usrinfo() passing either secid obtained from current thread's context or secid == 0? It seems to me that they are. If I didn't miss something, we don't need to pass secid to xfrm_audit_helper_usrinfo() because audit_log_task_context() will obtain secid from current thread's context. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Diffstat (limited to 'net/xfrm/xfrm_replay.c')
0 files changed, 0 insertions, 0 deletions