Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

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: ---
Bug Depends On:    
Bug Blocks: 224041    
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.