Bug 228927 - LSPP: odd audit argument on some 32 bit syscalls
Summary: LSPP: odd audit argument on some 32 bit syscalls
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: audit
Version: 5.0
Hardware: s390x
OS: Linux
Target Milestone: ---
: ---
Assignee: Steve Grubb
QA Contact: Brian Brock
Depends On:
Blocks: RHEL5LSPPCertTracker 227613
TreeView+ depends on / blocked
Reported: 2007-02-15 21:55 UTC by Kylene J Hall
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-03-05 22:37:31 UTC
Target Upstream Version:

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

Description Kylene J Hall 2007-02-15 21:55:58 UTC
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 21:55:58 UTC
Created attachment 148150 [details]
Brief testcase

Comment 2 Kylene J Hall 2007-02-15 22:02:57 UTC
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 22:37:31 UTC
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.