Bug 204927

Summary: [LSPP Audit] Incorrect value produced in shmat syscall audit record for success field.
Product: Red Hat Enterprise Linux 5 Reporter: IBM Bug Proxy <bugproxy>
Component: kernelAssignee: David Woodhouse <dwmw2>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: high    
Version: 5.0CC: aviro, dwmw2, dzickus, eparis, iboverma, sgrubb
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: powerpc   
OS: Linux   
Whiteboard:
Fixed In Version: 5.0.0 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-11-17 14:35:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description IBM Bug Proxy 2006-09-01 13:26:11 UTC
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 18:30:59 UTC
----- 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 20:34:42 UTC
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 14:12:30 UTC
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 18:10:58 UTC
------- 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 19:53:15 UTC
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 19:55:21 UTC
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 14:55:17 UTC
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 13:22:54 UTC
Yes, it does. Patch applied to kernel CVS tree and sent upstream.

Comment 16 Jay Turner 2006-11-17 14:34:15 UTC
Verified in 2.6.18-1.2747.el5.