Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 228927

Summary: LSPP: odd audit argument on some 32 bit syscalls
Product: Red Hat Enterprise Linux 5 Reporter: Kylene J Hall <kylene>
Component: auditAssignee: Steve Grubb <sgrubb>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0CC: borgan, iboverma, linda.knippers
Target Milestone: ---   
Target Release: ---   
Hardware: s390x   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-03-05 22:37:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 224041, 227613    
Attachments:
Description Flags
Brief testcase none

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
comm="a.out"
exe="/rhcc/lspp/tests/LTP/ltp-merged/testcases/audit/syscalls/a.out"
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:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223864

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.