Bug 228927 - LSPP: odd audit argument on some 32 bit syscalls
LSPP: odd audit argument on some 32 bit syscalls
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: audit (Show other bugs)
s390x Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Grubb
Brian Brock
Depends On:
Blocks: RHEL5LSPPCertTracker 227613
  Show dependency treegraph
Reported: 2007-02-15 16:55 EST by Kylene J Hall
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-05 17:37:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Brief testcase (375 bytes, text/plain)
2007-02-15 16:55 EST, Kylene J Hall
no flags Details

  None (edit)
Description Kylene J Hall 2007-02-15 16:55:58 EST
Description of problem:
I don't think this is really necessarily an audit bug but didn't know what to
open against and I found it when testing audit.  When running some system calls
in 32 bit mode on s390x the 4th argument (a3) ends up larger than 32 bits with a
stange number apparently OR'ed with the expected result.  This value is not
constant.  Yesterday I was seeing 0x4900000000 OR'ed with my expected value. 
Today (after a reboot) the value is 0x4700000000.  The value also appears to
already be OR'ed with the expected value when the call is made to the kernel as
shown in the strace output.  Attached is the trivial testcase compiled with gcc
-m31 test.c.

Version-Release number of selected component (if applicable):
I am running on the latest RC with the usual LSPP packages updated to those in
dwalsh's people page repo + sgrubbs kernel and kernel-devel lspp.64.

How reproducible:
Always on s390x, Not on ppc64 (only places I have tested)

Steps to Reproduce:
1. auditctl -a exit,always -S fgetxattr
2. Compile and run the attached test case and look at audit log.
3. Rerun with strace -e fgetxattr a.out

Actual results:
 strace -e fgetxattr ./a.out
fgetxattr(3, umovestr: Input/output error
0x3ff0040069cptrace: umoven: Input/output error
, 0x3ff7f8c2848, 304942678516) = 25
RC: 25, Error: 0
Process 1551 detached

<audit log snip>
type=SYSCALL msg=audit(1171574999.507:133): arch=16 syscall=229 success=yes
exit=25 a0=3 a1=40069c a2=7fc14848 a3=47000001f4 items=0 ppid=1358 pid=1558
auid=502 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0
subj=abat_u:abat_r:abat_t:s0-s15:c0.c1023 key=(null)

Expected results:
Would expect the value in the fourth argument to the fgetxattr syscall to be 500
and the audit a3 value to by 0x1f4

Additional info:
Comment 1 Kylene J Hall 2007-02-15 16:55:58 EST
Created attachment 148150 [details]
Brief testcase
Comment 2 Kylene J Hall 2007-02-15 17:02:57 EST
Other system calls affected by this were first document here:

The list for easy refrence is: fchownat, fgetxattr, fsetxattr,
getxattr, lgetxattr, lsetxattr, mknodat, mmap, mq_timedsendreceive, mremap,
openat, ptrace, renameat, setxattr, linkat
Comment 7 Steve Grubb 2007-03-05 17:37:31 EST
This will be fixed by updating documentation in the configuration guide. Closing.

Note You need to log in before you can comment on or make changes to this bug.