Bug 204927 - [LSPP Audit] Incorrect value produced in shmat syscall audit record for success field.
[LSPP Audit] Incorrect value produced in shmat syscall audit record for succe...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
powerpc Linux
high Severity high
: ---
: ---
Assigned To: David Woodhouse
Brian Brock
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-01 09:26 EDT by IBM Bug Proxy
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version: 5.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-17 09:35:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 26799 None None None Never

  None (edit)
Description IBM Bug Proxy 2006-09-01 09:26:11 EDT
LTC Owner is: mcthomps@us.ibm.com
LTC Originator is: mcthomps@us.ibm.com


---Problem Description---
Auditing of an an unsuccessful shmat call, results in an incorrect audit record
(success field).

The audit record is produced:
type=SYSCALL msg=audit(1157053309.404:529): arch=14 syscall=117 success=yes exit
=-13 a0=15 a1=218000 a2=2000 a3=fa94f728 items=0 ppid=2160 pid=16548 auid=0 uid=
500 gid=500 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=pts0 comm="s
hmat_test" exe="/rhcc/lspp/tests/LTP/ltp-merged/testcases/audit/syscalls/shmat_t
est" subj=root:system_r:unconfined_t:s0-s0:c0.c255 key=(null)
type=IPC msg=audit(1157053309.404:529): ouid=0 ogid=0 mode=1c0 obj=root:system_r
:unconfined_t:s0-s0:c0.c255

This in incorrect, success=yes should be success=no.
 
Contact Information = Michael Thompson mcthomps@us.ibm.com
 
---uname output---
Linux bladeracer2.ltc.austin.ibm.com 2.6.17-1.2586.2.2.fc6.lspp.48 #1 SMP Wed
Aug 30 15:57:21 EDT 2006 ppc64 ppc64 ppc64 GNU/Linux
 
Machine Type = ppc64, 32-bit execution
 
---Debugger---
A debugger is not configured
 
---Steps to Reproduce---
auditctl -a entry,always -S ipc
Execute an unsuccessful shmat call.

The following audit record is produced:
type=SYSCALL msg=audit(1157053309.404:529): arch=14 syscall=117 success=yes exit
=-13 a0=15 a1=218000 a2=2000 a3=fa94f728 items=0 ppid=2160 pid=16548 auid=0 uid=
500 gid=500 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=pts0 comm="s
hmat_test" exe="/rhcc/lspp/tests/LTP/ltp-merged/testcases/audit/syscalls/shmat_t
est" subj=root:system_r:unconfined_t:s0-s0:c0.c255 key=(null)
type=IPC msg=audit(1157053309.404:529): ouid=0 ogid=0 mode=1c0 obj=root:system_r
:unconfined_t:s0-s0:c0.c255

This in incorrect, success=yes should be success=no.
 
---Kernel Component Data--- 
Stack trace output:
  no
 
Oops output:
  no
 
System Dump Info:
  The system is not configured to capture a system dump.
 
*Additional Instructions for Michael Thompson mcthomps@us.ibm.com: 
-Attach sysctl -a output output to the bug.
Comment 1 IBM Bug Proxy 2006-09-05 14:30:59 EDT
----- Additional Comments From mcthomps@us.ibm.com  2006-09-05 14:26 EDT -------
Update: this error also exists for the following system calls (still with the
lspp.48 kernel)
shmat
shmctl
shmdt
shmget
unshare

The error is success=yes when the system call is failing. 
Comment 3 Steve Grubb 2006-09-14 16:34:42 EDT
Changing this bug to kernel since its likely a kernel problem. The syscall
record clearly shows exit of -13 and success is yes.
Comment 8 David Woodhouse 2006-09-19 10:12:30 EDT
Does this happen for both ppc32 and ppc64 userspace? If you use gdb, is the
error bit (ccr & 0x1000) actually set when we return to userspace from the
system call?
Comment 9 IBM Bug Proxy 2006-09-19 14:10:58 EDT
------- Additional Comments From mcthomps@us.ibm.com  2006-09-19 14:06 EDT -------
(In reply to comment #13)
> Does this happen for both ppc32 and ppc64 userspace? If you use gdb, is the
> error bit (ccr & 0x1000) actually set when we return to userspace from the
> system call?
> --

32-bit:
shmat(917510, 0, SHM_RND)               = -1 EACCES (Permission denied)

Resulting syscall record (32-bit):
type=SYSCALL msg=audit(1158689064.434:60748): arch=14 syscall=117 success=yes 
exit=-13 a0=15 a1=140006 a2=2000 a3=fac1f728 items=0 ppid=15193 pid=15009 
auid=0 uid=501 gid=501 euid=501 suid=0 fsuid=501 egid=501 sgid=0 fsgid=501 
tty=pts0 comm="shmat_test" exe="/rhcc/lspp/tests/LTP/ltp-
merged/testcases/audit/syscalls/shmat_test" 
subj=root:staff_r:staff_crontab_t:s0-s15:c0.c255 key=(null)

64-bit:
shmat(1114118, 0, SHM_RND)              = -1 EACCES (Permission denied)

Resulting syscall record (64-bit):
type=SYSCALL msg=audit(1158682601.953:60670): arch=80000015 syscall=117 
success=yes exit=-13 a0=15 a1=110006 a2=2000 a3=ffffe94f340 items=0 ppid=17482 
pid=17483 auid=0 uid=501 gid=501 euid=501 suid=0 fsuid=501 egid=501 sgid=0 
fsgid=501 tty=pts0 comm="shmat_test" exe="/rhcc/lspp/tests/LTP/ltp-
merged/testcases/audit/syscalls/shmat_test" subj=root:staff_r:staff_t:s0-
s15:c0.c255 key=(null) 
Comment 11 Steve Grubb 2006-09-19 15:53:15 EDT
Regarding comment #9, this is audit records which is not useful for this
particular bug. We need the register values that David had asked for in comment
#8. Thanks.
Comment 12 Alexander Viro 2006-09-20 15:55:21 EDT
syscall list is extremely odd.  Something special about sys_ipc()
guts is one thing; but seeing sys_unshare() in the list...  What
about simple close(-1)?  What records does it generate on ppc, both
from 64bit and 32bit tasks?  sys_close() and sys_unshare() should
be treated exactly the same way...

 
Comment 13 David Woodhouse 2006-09-21 10:55:17 EDT
Does this fix it?
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -553,7 +553,7 @@ #ifdef CONFIG_PPC32
 #endif

        if (unlikely(current->audit_context))
-              
audit_syscall_exit((regs->ccr&0x1000)?AUDITSC_FAILURE:AUDITSC_SUCCESS,
+              
audit_syscall_exit((regs->ccr&0x10000000)?AUDITSC_FAILURE:AUDITSC_SUCCESS,
                                   regs->result);

        if ((test_thread_flag(TIF_SYSCALL_TRACE)
Comment 14 David Woodhouse 2006-09-22 09:22:54 EDT
Yes, it does. Patch applied to kernel CVS tree and sent upstream.
Comment 16 Jay Turner 2006-11-17 09:34:15 EST
Verified in 2.6.18-1.2747.el5.

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