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 - LSPP: odd audit argument on some 32 bit syscalls
Summary: LSPP: odd audit argument on some 32 bit syscalls
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: audit
Version: 5.0
Hardware: s390x
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Steve Grubb
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: RHEL5LSPPCertTracker
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:
Environment:
Last Closed: 2007-03-05 22:37:31 UTC


Attachments (Terms of Use)
Brief testcase (deleted)
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
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.


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