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: | kernel | Assignee: | David Woodhouse <dwmw2> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 5.0 | CC: | 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
IBM Bug Proxy
2006-09-01 13:26:11 UTC
----- Additional Comments From mcthomps.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. Changing this bug to kernel since its likely a kernel problem. The syscall record clearly shows exit of -13 and success is yes. 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? ------- Additional Comments From mcthomps.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) 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. 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... 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)
Yes, it does. Patch applied to kernel CVS tree and sent upstream. Verified in 2.6.18-1.2747.el5. |