[PATCH] Audit: fix audit watch use after free
by Eric Paris
When an audit watch is added to a parent the temporary watch inside the
original krule from userspace is freed. Yet the original watch is used after
the real watch was created in audit_add_rules()
Signed-off-by: Eric Paris <eparis(a)redhat.com>
---
kernel/auditfilter.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 713098e..19c0a0a 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -1320,6 +1320,8 @@ static inline int audit_add_rule(struct audit_entry *entry)
mutex_unlock(&audit_filter_mutex);
goto error;
}
+ /* entry->rule.watch may have changed during audit_add_watch() */
+ watch = entry->rule.watch;
h = audit_hash_ino((u32)watch->ino);
list = &audit_inode_hash[h];
}
15 years, 7 months
- 1
- 0
audit rotate question
by LC Bruzenak
If I do a "service auditd rotate" it just sends the auditd the USR1
signal which means "start the rotation".
On a slow/burdened machine with many files this is not immediate.
I am trying to run a cron job which will :
mkdir /var/log/audit-archive/
service auditd rotate
mv /var/log/audit/audit.log.* /var/log/audit-archive/
But the files listed are not through rotating so it has issues (file not
found, leaves behind the last one rotated - audit.log.1, etc.).
How can I tell when the rotate is complete so I can move the files out?
I'm sure there is a simple way but I cannot see it.
Thx,
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
15 years, 7 months
- 3
- 3
Audit not recording the correct syscall return value in Fedora 10?
by Paul Moore
While doing some testing on Fedora 10 using the 2.6.27.5-117.fc10.x86_64
kernel I stumbled across a rather odd problem: somewhere between the end of
sys_sendto() and audit_syscall_exit() the syscall's return value was changing
resulting in incorrect audit records (similar problems with sys_sendmsg()).
After some head scratching and debugging I determined that the %rax register
was being altered at some point and if we reloaded the syscall's return value
from the stack before calling audit_syscall_exit() we could avoid the problem
(see patch below).
I also tried to reproduce the problem with a vanilla 2.6.29.1 kernel and after
several hours of testing I have yet to see the problem using the newer,
upstream kernel. Taking a look at the entry_64.S files of the two kernels
there appear to be a number of changes, the most significant are the tracing
changes but I'm not familiar enough with this chunk of code to identify the
definitive root cause (although, tracing changes does sound reasonable).
Does anyone have any thoughts?
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index a331ec3..16db517 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -589,8 +589,8 @@ auditsys:
* masked off.
*/
sysret_audit:
- movq %rax,%rsi /* second arg, syscall return value */
- cmpq $0,%rax /* is it < 0? */
+ movq RAX-ARGOFFSET(%rsp),%rsi /* second arg, syscall return value */
+ cmpq $0,%rsi /* is it < 0? */
setl %al /* 1 if so, 0 if not */
movzbl %al,%edi /* zero-extend that into %edi */
inc %edi /* first arg, 0->1(AUDITSC_SUCCESS), 1->2(AUDITSC_FAILURE) */
--
paul moore
linux @ hp
15 years, 7 months
- 3
- 11