Bug 242938 - audit(4) records the wrong exit code for execve()
Summary: audit(4) records the wrong exit code for execve()
Status: Closed DUPLICATE of bug 249179
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-audit Mailing List (Nobody)
Depends on:
Reported: 2019-12-28 12:20 UTC by ben
Modified: 2022-10-24 22:32 UTC (History)
5 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description ben 2019-12-28 12:20:10 UTC
It seems that audit is recording an errno of EJUSTRETURN instead of 0 for calls to execve().  This makes an audit policy with +ex ineffective.

header_ex,301,11,execve(2),0,::1,Sat Dec 28 12:10:13 2019, + 102 msec
exec arg,/usr/libexec/atrun
return,failure: Unknown error: 201,4294967295

I suspect D13180/r326145, but haven't investigated further.
Comment 1 ben 2020-10-27 11:47:43 UTC

*** This bug has been marked as a duplicate of bug 249179 ***
Comment 2 Kyle Evans freebsd_committer freebsd_triage 2020-10-27 12:06:25 UTC
Sorry for having missed this report. =(
Comment 3 commit-hook freebsd_committer freebsd_triage 2020-10-27 13:13:42 UTC
A commit references this bug:

Author: kevans
Date: Tue Oct 27 13:13:06 UTC 2020
New revision: 367080
URL: https://svnweb.freebsd.org/changeset/base/367080

  MFC r367002, r367060

  audit: correct reporting of *execve(2) success

  r326145 corrected do_execve() to return EJUSTRETURN upon success so that
  important registers are not clobbered. This had the side effect of tapping
  out 'failures' for all *execve(2) audit records, which is less than useful
  for auditing purposes.

  Audit exec returns earlier, where we can know for sure that EJUSTRETURN
  translates to success. Note that this unsets TDP_AUDITREC as we commit the
  audit record, so the usual audit in the syscall return path will do nothing.

  audit: also correctly audit linux_execve()

  Linux execve() gets audited as AUE_EXECVE as well, we should also interpret
  the return from this correctly for the same reasoning as in r367002.

  PR:		249179, 242938

_U  stable/12/