Re: splat in kretprobe in get_task_mm(current)
On Wed, Jun 04 2014 at 15:49, Masami Hiramatsu wrote: > Here, as you can see, calling mmput() in kretprobe handler is actually the > root cause > of this problem. Indeed, deferring the mmput to a workqueue solved my issue. Thanks for your quick reply today! Cheers, peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: splat in kretprobe in get_task_mm(current)
On Wed, Jun 04 2014 at 15:49, Masami Hiramatsu wrote: Here, as you can see, calling mmput() in kretprobe handler is actually the root cause of this problem. Indeed, deferring the mmput to a workqueue solved my issue. Thanks for your quick reply today! Cheers, peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: splat in kretprobe in get_task_mm(current)
As a follow up, I can reliably reproduce this bug with the following code
#include
#include
int main(int argc, char *argv[]) {
char *envp_[] = {NULL};
char *argv_[] = {argv[0]};
execve(argv[0], argv_, envp_);
return 0;
}
run in parallel like so:
$ for x in $(seq 0 32) ; do ./a.out & done
giving me the following splat:.
[ 133.627336] BUG: spinlock cpu recursion on CPU#4, a.out/4643
[ 133.627346] lock: kretprobe_table_locks+0x1b80/0x2000, .magic: dead4ead,
.owner: a.out/4630, .owner_cpu: 4
[ 133.627350] CPU: 4 PID: 4643 Comm: a.out Tainted: G IOE
3.15.0-rc8-splat+ #14
[ 133.627351] Hardware name: Dell Inc. Precision WorkStation T3500 /09KPNV,
BIOS A10 01/21/2011
[ 133.627353] 8804d5ae 8804a7b4fd48 81773413
0007
[ 133.627358] 82843600 8804a7b4fd68 8176ec74
82843600
[ 133.627362] 81a8b6a6 8804a7b4fd88 8176ec9f
82843600
[ 133.627366] Call Trace:
[ 133.627372] [] dump_stack+0x46/0x58
[ 133.627376] [] spin_dump+0x8f/0x94
[ 133.627379] [] spin_bug+0x26/0x2b
[ 133.627384] [] do_raw_spin_lock+0x105/0x190
[ 133.627389] [] _raw_spin_lock_irqsave+0x70/0x90
[ 133.627394] [] ? kretprobe_hash_lock+0x6c/0x80
[ 133.627398] [] ? mutex_unlock+0xe/0x10
[ 133.627401] [] kretprobe_hash_lock+0x6c/0x80
[ 133.627404] [] trampoline_handler+0x3d/0x220
[ 133.627407] [] kretprobe_trampoline+0x25/0x57
[ 133.627412] [] ? do_execve+0x18/0x20
[ 133.627415] [] stub_execve+0x69/0xa0
On Tue, Jun 03 2014 at 10:39, Peter Moody wrote:
> Hi folks,
>
> I've managed to trigger the following splat on 3.15.0-rc8 using the attached
> kretprobe module.
>
> [ 339.208634] BUG: spinlock cpu recursion on CPU#4, rm/8733
> [ 339.208643] lock: kretprobe_table_locks+0x600/0x2000, .magic: dead4ead,
> .owner: rm/8734, .owner_cpu: 4
> [ 339.208647] CPU: 4 PID: 8733 Comm: rm Tainted: G IOE
> 3.15.0-rc8-splat+ #14
> [ 339.208648] Hardware name: Dell Inc. Precision WorkStation T3500 /09KPNV,
> BIOS A10 01/21/2011
> [ 339.208650] 88044d3a2570 880454e63d48 81773413
> 0007
> [ 339.208654] 82842080 880454e63d68 8176ec74
> 82842080
> [ 339.208658] 81a8b6a6 880454e63d88 8176ec9f
> 82842080
> [ 339.208662] Call Trace:
> [ 339.208667] [] dump_stack+0x46/0x58
> [ 339.208671] [] spin_dump+0x8f/0x94
> [ 339.208674] [] spin_bug+0x26/0x2b
> [ 339.208678] [] do_raw_spin_lock+0x105/0x190
> [ 339.208683] [] _raw_spin_lock_irqsave+0x70/0x90
> [ 339.208687] [] ? kretprobe_hash_lock+0x6c/0x80
> [ 339.208690] [] ? mutex_unlock+0xe/0x10
> [ 339.208693] [] kretprobe_hash_lock+0x6c/0x80
> [ 339.208697] [] trampoline_handler+0x3d/0x220
> [ 339.208700] [] ? kfree+0x147/0x190
> [ 339.208703] [] kretprobe_trampoline+0x25/0x57
> [ 339.208707] [] ? do_execve+0x18/0x20
> [ 339.208710] [] stub_execve+0x69/0xa0
>
> Unfortunately triggering the splat is kind of a pain. I've only been able to
> it by building chromeos. The cros build
> process kicks off dozens of processes (in this case, it was 32) to
> fetch/build the various packages for the system
> image. I can try to come up with a better reproducer if this splat and module
> aren't enough.
>
> If I remove getting the reference to mm, I avoid the splat.
>
> Cheers,
> peter
>
>
> #include
> #include
> #include
> #include
> #include
>
> static int cntr;
>
> static int exec_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
> {
> int ret = (int)regs_return_value(regs);
> if (!(unlikely(IS_ERR_VALUE(ret {
> struct mm_struct *mm = NULL;
> mm = get_task_mm(current);
> if (mm)
>mmput(mm);
> }
> return 0;
> }
>
> static struct kretprobe exec_kretprobe = {
> .kp.symbol_name = "do_execve",
> .handler = exec_handler,
> };
>
> static int __init probe_init(void)
> {
> int err;
> if ((err = register_kretprobe(_kretprobe))) {
> pr_err("register failed: %d\n", err);
> return err;
> }
> pr_info("exec_mm_probe loaded.\n");
> cntr = 0;
> return 0;
> }
>
> static void probe_exit(void)
> {
> unregister_kretprobe(_kretprobe);
> pr_info("exec_mm_probe unloaded.\n");
> }
>
> MODULE_LICENSE("GPL v2");
>
> module_init(probe_init);
> module_exit(probe_exit);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
splat in kretprobe in get_task_mm(current)
Hi folks,
I've managed to trigger the following splat on 3.15.0-rc8 using the attached
kretprobe module.
[ 339.208634] BUG: spinlock cpu recursion on CPU#4, rm/8733
[ 339.208643] lock: kretprobe_table_locks+0x600/0x2000, .magic: dead4ead,
.owner: rm/8734, .owner_cpu: 4
[ 339.208647] CPU: 4 PID: 8733 Comm: rm Tainted: G IOE
3.15.0-rc8-splat+ #14
[ 339.208648] Hardware name: Dell Inc. Precision WorkStation T3500 /09KPNV,
BIOS A10 01/21/2011
[ 339.208650] 88044d3a2570 880454e63d48 81773413
0007
[ 339.208654] 82842080 880454e63d68 8176ec74
82842080
[ 339.208658] 81a8b6a6 880454e63d88 8176ec9f
82842080
[ 339.208662] Call Trace:
[ 339.208667] [] dump_stack+0x46/0x58
[ 339.208671] [] spin_dump+0x8f/0x94
[ 339.208674] [] spin_bug+0x26/0x2b
[ 339.208678] [] do_raw_spin_lock+0x105/0x190
[ 339.208683] [] _raw_spin_lock_irqsave+0x70/0x90
[ 339.208687] [] ? kretprobe_hash_lock+0x6c/0x80
[ 339.208690] [] ? mutex_unlock+0xe/0x10
[ 339.208693] [] kretprobe_hash_lock+0x6c/0x80
[ 339.208697] [] trampoline_handler+0x3d/0x220
[ 339.208700] [] ? kfree+0x147/0x190
[ 339.208703] [] kretprobe_trampoline+0x25/0x57
[ 339.208707] [] ? do_execve+0x18/0x20
[ 339.208710] [] stub_execve+0x69/0xa0
Unfortunately triggering the splat is kind of a pain. I've only been able to it
by building chromeos. The cros build process kicks off dozens of processes (in
this case, it was 32) to fetch/build the various packages for the system image.
I can try to come up with a better reproducer if this splat and module aren't
enough.
If I remove getting the reference to mm, I avoid the splat.
Cheers,
peter
#include
#include
#include
#include
#include
static int cntr;
static int exec_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
{
int ret = (int)regs_return_value(regs);
if (!(unlikely(IS_ERR_VALUE(ret {
struct mm_struct *mm = NULL;
mm = get_task_mm(current);
if (mm)
mmput(mm);
}
return 0;
}
static struct kretprobe exec_kretprobe = {
.kp.symbol_name = "do_execve",
.handler = exec_handler,
};
static int __init probe_init(void)
{
int err;
if ((err = register_kretprobe(_kretprobe))) {
pr_err("register failed: %d\n", err);
return err;
}
pr_info("exec_mm_probe loaded.\n");
cntr = 0;
return 0;
}
static void probe_exit(void)
{
unregister_kretprobe(_kretprobe);
pr_info("exec_mm_probe unloaded.\n");
}
MODULE_LICENSE("GPL v2");
module_init(probe_init);
module_exit(probe_exit);
splat in kretprobe in get_task_mm(current)
Hi folks,
I've managed to trigger the following splat on 3.15.0-rc8 using the attached
kretprobe module.
[ 339.208634] BUG: spinlock cpu recursion on CPU#4, rm/8733
[ 339.208643] lock: kretprobe_table_locks+0x600/0x2000, .magic: dead4ead,
.owner: rm/8734, .owner_cpu: 4
[ 339.208647] CPU: 4 PID: 8733 Comm: rm Tainted: G IOE
3.15.0-rc8-splat+ #14
[ 339.208648] Hardware name: Dell Inc. Precision WorkStation T3500 /09KPNV,
BIOS A10 01/21/2011
[ 339.208650] 88044d3a2570 880454e63d48 81773413
0007
[ 339.208654] 82842080 880454e63d68 8176ec74
82842080
[ 339.208658] 81a8b6a6 880454e63d88 8176ec9f
82842080
[ 339.208662] Call Trace:
[ 339.208667] [81773413] dump_stack+0x46/0x58
[ 339.208671] [8176ec74] spin_dump+0x8f/0x94
[ 339.208674] [8176ec9f] spin_bug+0x26/0x2b
[ 339.208678] [810c4195] do_raw_spin_lock+0x105/0x190
[ 339.208683] [8177c7c0] _raw_spin_lock_irqsave+0x70/0x90
[ 339.208687] [817839dc] ? kretprobe_hash_lock+0x6c/0x80
[ 339.208690] [8177a86e] ? mutex_unlock+0xe/0x10
[ 339.208693] [817839dc] kretprobe_hash_lock+0x6c/0x80
[ 339.208697] [8177f16d] trampoline_handler+0x3d/0x220
[ 339.208700] [811bc537] ? kfree+0x147/0x190
[ 339.208703] [8177f0fe] kretprobe_trampoline+0x25/0x57
[ 339.208707] [811e28e8] ? do_execve+0x18/0x20
[ 339.208710] [817862a9] stub_execve+0x69/0xa0
Unfortunately triggering the splat is kind of a pain. I've only been able to it
by building chromeos. The cros build process kicks off dozens of processes (in
this case, it was 32) to fetch/build the various packages for the system image.
I can try to come up with a better reproducer if this splat and module aren't
enough.
If I remove getting the reference to mm, I avoid the splat.
Cheers,
peter
#include linux/version.h
#include linux/kernel.h
#include linux/module.h
#include linux/mm.h
#include linux/kprobes.h
static int cntr;
static int exec_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
{
int ret = (int)regs_return_value(regs);
if (!(unlikely(IS_ERR_VALUE(ret {
struct mm_struct *mm = NULL;
mm = get_task_mm(current);
if (mm)
mmput(mm);
}
return 0;
}
static struct kretprobe exec_kretprobe = {
.kp.symbol_name = do_execve,
.handler = exec_handler,
};
static int __init probe_init(void)
{
int err;
if ((err = register_kretprobe(exec_kretprobe))) {
pr_err(register failed: %d\n, err);
return err;
}
pr_info(exec_mm_probe loaded.\n);
cntr = 0;
return 0;
}
static void probe_exit(void)
{
unregister_kretprobe(exec_kretprobe);
pr_info(exec_mm_probe unloaded.\n);
}
MODULE_LICENSE(GPL v2);
module_init(probe_init);
module_exit(probe_exit);
Re: splat in kretprobe in get_task_mm(current)
As a follow up, I can reliably reproduce this bug with the following code
#include unistd.h
#include sys/types.h
int main(int argc, char *argv[]) {
char *envp_[] = {NULL};
char *argv_[] = {argv[0]};
execve(argv[0], argv_, envp_);
return 0;
}
run in parallel like so:
$ for x in $(seq 0 32) ; do ./a.out done
giving me the following splat:.
[ 133.627336] BUG: spinlock cpu recursion on CPU#4, a.out/4643
[ 133.627346] lock: kretprobe_table_locks+0x1b80/0x2000, .magic: dead4ead,
.owner: a.out/4630, .owner_cpu: 4
[ 133.627350] CPU: 4 PID: 4643 Comm: a.out Tainted: G IOE
3.15.0-rc8-splat+ #14
[ 133.627351] Hardware name: Dell Inc. Precision WorkStation T3500 /09KPNV,
BIOS A10 01/21/2011
[ 133.627353] 8804d5ae 8804a7b4fd48 81773413
0007
[ 133.627358] 82843600 8804a7b4fd68 8176ec74
82843600
[ 133.627362] 81a8b6a6 8804a7b4fd88 8176ec9f
82843600
[ 133.627366] Call Trace:
[ 133.627372] [81773413] dump_stack+0x46/0x58
[ 133.627376] [8176ec74] spin_dump+0x8f/0x94
[ 133.627379] [8176ec9f] spin_bug+0x26/0x2b
[ 133.627384] [810c4195] do_raw_spin_lock+0x105/0x190
[ 133.627389] [8177c7c0] _raw_spin_lock_irqsave+0x70/0x90
[ 133.627394] [817839dc] ? kretprobe_hash_lock+0x6c/0x80
[ 133.627398] [8177a86e] ? mutex_unlock+0xe/0x10
[ 133.627401] [817839dc] kretprobe_hash_lock+0x6c/0x80
[ 133.627404] [8177f16d] trampoline_handler+0x3d/0x220
[ 133.627407] [8177f0fe] kretprobe_trampoline+0x25/0x57
[ 133.627412] [811e28e8] ? do_execve+0x18/0x20
[ 133.627415] [817862a9] stub_execve+0x69/0xa0
On Tue, Jun 03 2014 at 10:39, Peter Moody wrote:
Hi folks,
I've managed to trigger the following splat on 3.15.0-rc8 using the attached
kretprobe module.
[ 339.208634] BUG: spinlock cpu recursion on CPU#4, rm/8733
[ 339.208643] lock: kretprobe_table_locks+0x600/0x2000, .magic: dead4ead,
.owner: rm/8734, .owner_cpu: 4
[ 339.208647] CPU: 4 PID: 8733 Comm: rm Tainted: G IOE
3.15.0-rc8-splat+ #14
[ 339.208648] Hardware name: Dell Inc. Precision WorkStation T3500 /09KPNV,
BIOS A10 01/21/2011
[ 339.208650] 88044d3a2570 880454e63d48 81773413
0007
[ 339.208654] 82842080 880454e63d68 8176ec74
82842080
[ 339.208658] 81a8b6a6 880454e63d88 8176ec9f
82842080
[ 339.208662] Call Trace:
[ 339.208667] [81773413] dump_stack+0x46/0x58
[ 339.208671] [8176ec74] spin_dump+0x8f/0x94
[ 339.208674] [8176ec9f] spin_bug+0x26/0x2b
[ 339.208678] [810c4195] do_raw_spin_lock+0x105/0x190
[ 339.208683] [8177c7c0] _raw_spin_lock_irqsave+0x70/0x90
[ 339.208687] [817839dc] ? kretprobe_hash_lock+0x6c/0x80
[ 339.208690] [8177a86e] ? mutex_unlock+0xe/0x10
[ 339.208693] [817839dc] kretprobe_hash_lock+0x6c/0x80
[ 339.208697] [8177f16d] trampoline_handler+0x3d/0x220
[ 339.208700] [811bc537] ? kfree+0x147/0x190
[ 339.208703] [8177f0fe] kretprobe_trampoline+0x25/0x57
[ 339.208707] [811e28e8] ? do_execve+0x18/0x20
[ 339.208710] [817862a9] stub_execve+0x69/0xa0
Unfortunately triggering the splat is kind of a pain. I've only been able to
it by building chromeos. The cros build
process kicks off dozens of processes (in this case, it was 32) to
fetch/build the various packages for the system
image. I can try to come up with a better reproducer if this splat and module
aren't enough.
If I remove getting the reference to mm, I avoid the splat.
Cheers,
peter
#include linux/version.h
#include linux/kernel.h
#include linux/module.h
#include linux/mm.h
#include linux/kprobes.h
static int cntr;
static int exec_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
{
int ret = (int)regs_return_value(regs);
if (!(unlikely(IS_ERR_VALUE(ret {
struct mm_struct *mm = NULL;
mm = get_task_mm(current);
if (mm)
mmput(mm);
}
return 0;
}
static struct kretprobe exec_kretprobe = {
.kp.symbol_name = do_execve,
.handler = exec_handler,
};
static int __init probe_init(void)
{
int err;
if ((err = register_kretprobe(exec_kretprobe))) {
pr_err(register failed: %d\n, err);
return err;
}
pr_info(exec_mm_probe loaded.\n);
cntr = 0;
return 0;
}
static void probe_exit(void)
{
unregister_kretprobe(exec_kretprobe);
pr_info(exec_mm_probe unloaded.\n);
}
MODULE_LICENSE(GPL v2);
module_init(probe_init);
module_exit(probe_exit);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the userns tree with the security tree
Hey Eric (Paris), this is the second time I've been notified of a merge issue with this audit patch; Is there something I need to do (or should have done earlier) to keep this from continuing to be an issue? Cheers, peter On Mon, Sep 24, 2012 at 5:17 AM, Stephen Rothwell wrote: > Hi, > > On Mon, 24 Sep 2012 21:41:16 +1000 Stephen Rothwell > wrote: >> >> diff --cc kernel/auditsc.c >> index 37f52f2,ff4798f..000 >> --- a/kernel/auditsc.c >> +++ b/kernel/auditsc.c >> @@@ -1160,32 -1151,8 +1152,38 @@@ void audit_log_task_info(struct audit_b >> char name[sizeof(tsk->comm)]; >> struct mm_struct *mm = tsk->mm; >> struct vm_area_struct *vma; >> +char *tty; >> + >> +if (!ab) >> +return; >> >> /* tsk == current */ >> +cred = current_cred(); >> + >> +spin_lock_irq(>sighand->siglock); >> +if (tsk->signal && tsk->signal->tty && tsk->signal->tty->name) >> +tty = tsk->signal->tty->name; >> +else >> +tty = "(none)"; >> +spin_unlock_irq(>sighand->siglock); >> + >> + >> +audit_log_format(ab, >> + " ppid=%ld pid=%d auid=%u uid=%u gid=%u" >> + " euid=%u suid=%u fsuid=%u" >> + " egid=%u sgid=%u fsgid=%u ses=%u tty=%s", >> + sys_getppid(), >> + tsk->pid, >> - tsk->loginuid, cred->uid, cred->gid, >> - cred->euid, cred->suid, cred->fsuid, >> - cred->egid, cred->sgid, cred->fsgid, >> ++ from_kuid(_user_ns, tsk->loginuid), >> ++ from_kuid(_user_ns, context->uid), >> ++ from_kgid(_user_ns, context->gid), >> ++ from_kuid(_user_ns, context->euid), >> ++ from_kuid(_user_ns, context->suid), >> ++ from_kuid(_user_ns, context->fsuid), >> ++ from_kgid(_user_ns, context->egid), >> ++ from_kgid(_user_ns, context->sgid), >> ++ from_kgid(_user_ns, context->fsgid), > > These should all be "cred" not "context", of course. I fixed this in my > tree. > > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au -- Peter Moody Google1.650.253.7306 Security Engineer pgp:0xC3410038 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the userns tree with the security tree
Hey Eric (Paris), this is the second time I've been notified of a merge issue with this audit patch; Is there something I need to do (or should have done earlier) to keep this from continuing to be an issue? Cheers, peter On Mon, Sep 24, 2012 at 5:17 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi, On Mon, 24 Sep 2012 21:41:16 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: diff --cc kernel/auditsc.c index 37f52f2,ff4798f..000 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@@ -1160,32 -1151,8 +1152,38 @@@ void audit_log_task_info(struct audit_b char name[sizeof(tsk-comm)]; struct mm_struct *mm = tsk-mm; struct vm_area_struct *vma; +char *tty; + +if (!ab) +return; /* tsk == current */ +cred = current_cred(); + +spin_lock_irq(tsk-sighand-siglock); +if (tsk-signal tsk-signal-tty tsk-signal-tty-name) +tty = tsk-signal-tty-name; +else +tty = (none); +spin_unlock_irq(tsk-sighand-siglock); + + +audit_log_format(ab, + ppid=%ld pid=%d auid=%u uid=%u gid=%u + euid=%u suid=%u fsuid=%u + egid=%u sgid=%u fsgid=%u ses=%u tty=%s, + sys_getppid(), + tsk-pid, - tsk-loginuid, cred-uid, cred-gid, - cred-euid, cred-suid, cred-fsuid, - cred-egid, cred-sgid, cred-fsgid, ++ from_kuid(init_user_ns, tsk-loginuid), ++ from_kuid(init_user_ns, context-uid), ++ from_kgid(init_user_ns, context-gid), ++ from_kuid(init_user_ns, context-euid), ++ from_kuid(init_user_ns, context-suid), ++ from_kuid(init_user_ns, context-fsuid), ++ from_kgid(init_user_ns, context-egid), ++ from_kgid(init_user_ns, context-sgid), ++ from_kgid(init_user_ns, context-fsgid), These should all be cred not context, of course. I fixed this in my tree. -- Cheers, Stephen Rothwells...@canb.auug.org.au -- Peter Moody Google1.650.253.7306 Security Engineer pgp:0xC3410038 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in audit_copy_inode
On Wed, Aug 1, 2012 at 9:11 AM, Miklos Szeredi wrote: > Hi Peter, > > Thanks for the report. > > Here's a patch. I haven't tested it but I'm pretty confident that it > fixes the bug. > > Thanks, > Miklos Ack. I can confirm that I don't Oops with this patch. Thanks! Cheers, peter -- Peter Moody Google Security Engineer pgp:0xC3410038 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in audit_copy_inode
This time with a cleaner Oops: Pid: 2643, comm: cc1 Not tainted 3.5.0-rc6-at17+ #33 LENOVO 4291AK7/4291AK7 RIP: 0010:[] [] audit_copy_inode+0x10/0x90 RSP: 0018:8801f88dfc58 EFLAGS: 00010282 RAX: 8801fb32 RBX: 8801f887c508 RCX: c7e8 RDX: RSI: 8801f3f1d970 RDI: 8801f887c508 RBP: 8801f88dfc88 R08: R09: R10: 0001 R11: R12: 8801f3f1d970 R13: 8801f887c4a8 R14: R15: FS: 7fd6b9473700() GS:88021520() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0040 CR3: 00020f6a3000 CR4: 000407e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process cc1 (pid: 2643, threadinfo 8801f88de000, task 8801fb32) Stack: 8161c6fe 8801f887c508 8801f3f1d970 8801f887c4a8 8801f887c508 8801f3f1d970 8801f88dfcf8 810d237c 810d22bb 8801f3f1d970 8801f4575e40 Call Trace: [] ? mutex_unlock+0xe/0x10 [] __audit_inode+0x13c/0x2a0 [] ? __audit_inode+0x7b/0x2a0 [] do_last+0x7ac/0xa90 [] path_openat+0xd9/0x410 [] ? sched_clock_cpu+0xbd/0x110 [] ? native_sched_clock+0x13/0x80 [] ? sched_clock+0x9/0x10 [] do_filp_open+0x42/0xa0 [] ? _raw_spin_unlock+0x2b/0x40 [] ? alloc_fd+0xd2/0x120 [] do_sys_open+0xf8/0x1d0 [] ? __audit_syscall_entry+0xcc/0x310 [] sys_open+0x21/0x30 [] system_call_fastpath+0x16/0x1b Code: 00 00 c7 45 cc 1f 00 00 00 e9 2c ff ff ff 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 54 53 48 83 ec 20 66 66 66 66 90 <48> 8b 42 40 49 89 f4 48 8d 77 34 48 89 fb 48 89 47 18 48 8b 42 RIP [] audit_copy_inode+0x10/0x90 RSP CR2: 0040 ---[ end trace bcccee9a00e71a3b ]--- On Tue, Jul 31, 2012 at 4:02 PM, Peter Moody wrote: > I seem to have a reliable oops from 3.5.0-rc6 from Linus's tree. I've > bisected it down to, I think, the following commit: > > 7157486541bffc0dfec912e21ae639b029dae3d3 > > The Oops: > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.471368] Pid: 2643, comm: > cc1 Not tainted 3.5.0-rc6-at17+ #33 LENOVO 4291AK7/4291AK7 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.472342] RIP: > 0010:[] [] > audit_copy_inode+0x10/0x90 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.473300] RSP: > 0018:8801f88dfc58 EFLAGS: 00010282 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.474253] RAX: > 8801fb32 RBX: 8801f887c508 RCX: c7e8 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.475210] RDX: > RSI: 8801f3f1d970 RDI: 8801f887c508 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.476172] RBP: > 8801f88dfc88 R08: R09: > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.477138] R10: > 0001 R11: R12: 8801f3f1d970 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.478236] R13: > 8801f887c4a8 R14: R15: > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.479218] FS: > 7fd6b9473700() GS:88021520() > knlGS: > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.480182] CS: 0010 DS: > ES: CR0: 80050033 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.481143] CR2: > 0040 CR3: 00020f6a3000 CR4: 000407e0 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.482142] DR0: > DR1: DR2: > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.483121] DR3: > DR6: 0ff0 DR7: 0400 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.484094] Process cc1 (pid: > 2643, threadinfo 8801f88de000, task 8801fb32) > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.485070] Stack: > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.486030] 8161c6fe > 8801f887c508 8801f3f1d970 8801f887c4a8 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.487011] 8801f887c508 > 8801f3f1d970 8801f88dfcf8 810d237c > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.487995] 810d22bb > 8801f3f1d970 8801f4575e40 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.488981] Call Trace: > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.489957] > [] ? mutex_unlock+0xe/0x10 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.490934] > [] __audit_inode+0x13c/0x2a0 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.491927] > [] ? __audit_inode+0x7b/0x2a0 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.492916] > [] do_last+0x7ac/0xa90 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.493883] > [] path_openat+0xd9/0x410 > Jul 31 15:32:11 pmoody-x220 kernel: [ 108.494852] > [] ? sched_clock_cpu+0xbd/0x110 > Jul 31 15:32:11 pmoody-x220
Re: Oops in audit_copy_inode
This time with a cleaner Oops: Pid: 2643, comm: cc1 Not tainted 3.5.0-rc6-at17+ #33 LENOVO 4291AK7/4291AK7 RIP: 0010:[810cec30] [810cec30] audit_copy_inode+0x10/0x90 RSP: 0018:8801f88dfc58 EFLAGS: 00010282 RAX: 8801fb32 RBX: 8801f887c508 RCX: c7e8 RDX: RSI: 8801f3f1d970 RDI: 8801f887c508 RBP: 8801f88dfc88 R08: R09: R10: 0001 R11: R12: 8801f3f1d970 R13: 8801f887c4a8 R14: R15: FS: 7fd6b9473700() GS:88021520() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0040 CR3: 00020f6a3000 CR4: 000407e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process cc1 (pid: 2643, threadinfo 8801f88de000, task 8801fb32) Stack: 8161c6fe 8801f887c508 8801f3f1d970 8801f887c4a8 8801f887c508 8801f3f1d970 8801f88dfcf8 810d237c 810d22bb 8801f3f1d970 8801f4575e40 Call Trace: [8161c6fe] ? mutex_unlock+0xe/0x10 [810d237c] __audit_inode+0x13c/0x2a0 [810d22bb] ? __audit_inode+0x7b/0x2a0 [8117b44c] do_last+0x7ac/0xa90 [8117cad9] path_openat+0xd9/0x410 [81087f2d] ? sched_clock_cpu+0xbd/0x110 [8101a7a3] ? native_sched_clock+0x13/0x80 [8101a819] ? sched_clock+0x9/0x10 [8117cf32] do_filp_open+0x42/0xa0 [8161ed9b] ? _raw_spin_unlock+0x2b/0x40 [8118a2c2] ? alloc_fd+0xd2/0x120 [8116c2f8] do_sys_open+0xf8/0x1d0 [810d1a8c] ? __audit_syscall_entry+0xcc/0x310 [8116c3f1] sys_open+0x21/0x30 [81627529] system_call_fastpath+0x16/0x1b Code: 00 00 c7 45 cc 1f 00 00 00 e9 2c ff ff ff 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 54 53 48 83 ec 20 66 66 66 66 90 48 8b 42 40 49 89 f4 48 8d 77 34 48 89 fb 48 89 47 18 48 8b 42 RIP [810cec30] audit_copy_inode+0x10/0x90 RSP 8801f88dfc58 CR2: 0040 ---[ end trace bcccee9a00e71a3b ]--- On Tue, Jul 31, 2012 at 4:02 PM, Peter Moody pmo...@google.com wrote: I seem to have a reliable oops from 3.5.0-rc6 from Linus's tree. I've bisected it down to, I think, the following commit: 7157486541bffc0dfec912e21ae639b029dae3d3 The Oops: Jul 31 15:32:11 pmoody-x220 kernel: [ 108.471368] Pid: 2643, comm: cc1 Not tainted 3.5.0-rc6-at17+ #33 LENOVO 4291AK7/4291AK7 Jul 31 15:32:11 pmoody-x220 kernel: [ 108.472342] RIP: 0010:[810cec30] [810cec30] audit_copy_inode+0x10/0x90 Jul 31 15:32:11 pmoody-x220 kernel: [ 108.473300] RSP: 0018:8801f88dfc58 EFLAGS: 00010282 Jul 31 15:32:11 pmoody-x220 kernel: [ 108.474253] RAX: 8801fb32 RBX: 8801f887c508 RCX: c7e8 Jul 31 15:32:11 pmoody-x220 kernel: [ 108.475210] RDX: RSI: 8801f3f1d970 RDI: 8801f887c508 Jul 31 15:32:11 pmoody-x220 kernel: [ 108.476172] RBP: 8801f88dfc88 R08: R09: Jul 31 15:32:11 pmoody-x220 kernel: [ 108.477138] R10: 0001 R11: R12: 8801f3f1d970 Jul 31 15:32:11 pmoody-x220 kernel: [ 108.478236] R13: 8801f887c4a8 R14: R15: Jul 31 15:32:11 pmoody-x220 kernel: [ 108.479218] FS: 7fd6b9473700() GS:88021520() knlGS: Jul 31 15:32:11 pmoody-x220 kernel: [ 108.480182] CS: 0010 DS: ES: CR0: 80050033 Jul 31 15:32:11 pmoody-x220 kernel: [ 108.481143] CR2: 0040 CR3: 00020f6a3000 CR4: 000407e0 Jul 31 15:32:11 pmoody-x220 kernel: [ 108.482142] DR0: DR1: DR2: Jul 31 15:32:11 pmoody-x220 kernel: [ 108.483121] DR3: DR6: 0ff0 DR7: 0400 Jul 31 15:32:11 pmoody-x220 kernel: [ 108.484094] Process cc1 (pid: 2643, threadinfo 8801f88de000, task 8801fb32) Jul 31 15:32:11 pmoody-x220 kernel: [ 108.485070] Stack: Jul 31 15:32:11 pmoody-x220 kernel: [ 108.486030] 8161c6fe 8801f887c508 8801f3f1d970 8801f887c4a8 Jul 31 15:32:11 pmoody-x220 kernel: [ 108.487011] 8801f887c508 8801f3f1d970 8801f88dfcf8 810d237c Jul 31 15:32:11 pmoody-x220 kernel: [ 108.487995] 810d22bb 8801f3f1d970 8801f4575e40 Jul 31 15:32:11 pmoody-x220 kernel: [ 108.488981] Call Trace: Jul 31 15:32:11 pmoody-x220 kernel: [ 108.489957] [8161c6fe] ? mutex_unlock+0xe/0x10 Jul 31 15:32:11 pmoody-x220 kernel: [ 108.490934] [810d237c] __audit_inode+0x13c/0x2a0 Jul 31 15:32:11 pmoody-x220 kernel: [ 108.491927] [810d22bb] ? __audit_inode+0x7b/0x2a0 Jul 31 15:32:11 pmoody-x220 kernel: [ 108.492916] [8117b44c] do_last+0x7ac/0xa90 Jul 31 15:32:11
Re: Oops in audit_copy_inode
On Wed, Aug 1, 2012 at 9:11 AM, Miklos Szeredi mszer...@suse.cz wrote: Hi Peter, Thanks for the report. Here's a patch. I haven't tested it but I'm pretty confident that it fixes the bug. Thanks, Miklos Ack. I can confirm that I don't Oops with this patch. Thanks! Cheers, peter -- Peter Moody Google Security Engineer pgp:0xC3410038 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops in audit_copy_inode
I seem to have a reliable oops from 3.5.0-rc6 from Linus's tree. I've
bisected it down to, I think, the following commit:
7157486541bffc0dfec912e21ae639b029dae3d3
The Oops:
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.471368] Pid: 2643, comm:
cc1 Not tainted 3.5.0-rc6-at17+ #33 LENOVO 4291AK7/4291AK7
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.472342] RIP:
0010:[] []
audit_copy_inode+0x10/0x90
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.473300] RSP:
0018:8801f88dfc58 EFLAGS: 00010282
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.474253] RAX:
8801fb32 RBX: 8801f887c508 RCX: c7e8
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.475210] RDX:
RSI: 8801f3f1d970 RDI: 8801f887c508
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.476172] RBP:
8801f88dfc88 R08: R09:
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.477138] R10:
0001 R11: R12: 8801f3f1d970
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.478236] R13:
8801f887c4a8 R14: R15:
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.479218] FS:
7fd6b9473700() GS:88021520()
knlGS:
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.480182] CS: 0010 DS:
ES: CR0: 80050033
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.481143] CR2:
0040 CR3: 00020f6a3000 CR4: 000407e0
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.482142] DR0:
DR1: DR2:
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.483121] DR3:
DR6: 0ff0 DR7: 0400
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.484094] Process cc1 (pid:
2643, threadinfo 8801f88de000, task 8801fb32)
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.485070] Stack:
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.486030] 8161c6fe
8801f887c508 8801f3f1d970 8801f887c4a8
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.487011] 8801f887c508
8801f3f1d970 8801f88dfcf8 810d237c
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.487995] 810d22bb
8801f3f1d970 8801f4575e40
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.488981] Call Trace:
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.489957]
[] ? mutex_unlock+0xe/0x10
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.490934]
[] __audit_inode+0x13c/0x2a0
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.491927]
[] ? __audit_inode+0x7b/0x2a0
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.492916]
[] do_last+0x7ac/0xa90
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.493883]
[] path_openat+0xd9/0x410
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.494852]
[] ? sched_clock_cpu+0xbd/0x110
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.495817]
[] ? native_sched_clock+0x13/0x80
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.496774]
[] ? sched_clock+0x9/0x10
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.497721]
[] do_filp_open+0x42/0xa0
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.498663]
[] ? _raw_spin_unlock+0x2b/0x40
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.499609]
[] ? alloc_fd+0xd2/0x120
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.500579]
[] do_sys_open+0xf8/0x1d0
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.501514]
[] ? __audit_syscall_entry+0xcc/0x310
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.502471]
[] sys_open+0x21/0x30
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.503384]
[] system_call_fastpath+0x16/0x1b
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.504275] Code: 00 00 c7 45
cc 1f 00 00 00 e9 2c ff ff ff 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
55 48 89 e5 41 54 53 48 83 ec 20 66 66 66 66 90 <48> 8b 42 40 49 89 f4
48 8d 77 34 48 89 fb 48 89 47 18 48 8b 42
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.506188] RIP
[] audit_copy_inode+0x10/0x90
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.507108] RSP
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.508021] CR2: 0040
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.516307] ---[ end trace
bcccee9a00e71a3b ]---
I can generate this oops by doing the following:
sudo /etc/init.d/auditd start ; sudo auditctl -D ; sudo auditctl -a
exit,always -F arch=b64 -S chmod -k oops ; gcc hello.c
The macro expansion in hello.c seems to be important.
Other bits of likely pertinent information: Running Ubuntu.
auditd/auditctl version 1.7.13-1ubuntu2 (ancient..), gcc version
4.4.3.
Please let me know if there's anything else I can provide (but please
cc me, I'm not subscribed to lkml).
Cheers,
peter
--
Peter Moody Google
Security Engineer pgp:0xC3410038
#include
#define ME "!"
int main(void) {
printf("hello, world%s\n", ME);
return 0;
}
Oops in audit_copy_inode
I seem to have a reliable oops from 3.5.0-rc6 from Linus's tree. I've
bisected it down to, I think, the following commit:
7157486541bffc0dfec912e21ae639b029dae3d3
The Oops:
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.471368] Pid: 2643, comm:
cc1 Not tainted 3.5.0-rc6-at17+ #33 LENOVO 4291AK7/4291AK7
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.472342] RIP:
0010:[810cec30] [810cec30]
audit_copy_inode+0x10/0x90
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.473300] RSP:
0018:8801f88dfc58 EFLAGS: 00010282
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.474253] RAX:
8801fb32 RBX: 8801f887c508 RCX: c7e8
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.475210] RDX:
RSI: 8801f3f1d970 RDI: 8801f887c508
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.476172] RBP:
8801f88dfc88 R08: R09:
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.477138] R10:
0001 R11: R12: 8801f3f1d970
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.478236] R13:
8801f887c4a8 R14: R15:
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.479218] FS:
7fd6b9473700() GS:88021520()
knlGS:
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.480182] CS: 0010 DS:
ES: CR0: 80050033
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.481143] CR2:
0040 CR3: 00020f6a3000 CR4: 000407e0
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.482142] DR0:
DR1: DR2:
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.483121] DR3:
DR6: 0ff0 DR7: 0400
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.484094] Process cc1 (pid:
2643, threadinfo 8801f88de000, task 8801fb32)
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.485070] Stack:
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.486030] 8161c6fe
8801f887c508 8801f3f1d970 8801f887c4a8
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.487011] 8801f887c508
8801f3f1d970 8801f88dfcf8 810d237c
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.487995] 810d22bb
8801f3f1d970 8801f4575e40
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.488981] Call Trace:
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.489957]
[8161c6fe] ? mutex_unlock+0xe/0x10
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.490934]
[810d237c] __audit_inode+0x13c/0x2a0
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.491927]
[810d22bb] ? __audit_inode+0x7b/0x2a0
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.492916]
[8117b44c] do_last+0x7ac/0xa90
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.493883]
[8117cad9] path_openat+0xd9/0x410
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.494852]
[81087f2d] ? sched_clock_cpu+0xbd/0x110
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.495817]
[8101a7a3] ? native_sched_clock+0x13/0x80
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.496774]
[8101a819] ? sched_clock+0x9/0x10
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.497721]
[8117cf32] do_filp_open+0x42/0xa0
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.498663]
[8161ed9b] ? _raw_spin_unlock+0x2b/0x40
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.499609]
[8118a2c2] ? alloc_fd+0xd2/0x120
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.500579]
[8116c2f8] do_sys_open+0xf8/0x1d0
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.501514]
[810d1a8c] ? __audit_syscall_entry+0xcc/0x310
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.502471]
[8116c3f1] sys_open+0x21/0x30
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.503384]
[81627529] system_call_fastpath+0x16/0x1b
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.504275] Code: 00 00 c7 45
cc 1f 00 00 00 e9 2c ff ff ff 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
55 48 89 e5 41 54 53 48 83 ec 20 66 66 66 66 90 48 8b 42 40 49 89 f4
48 8d 77 34 48 89 fb 48 89 47 18 48 8b 42
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.506188] RIP
[810cec30] audit_copy_inode+0x10/0x90
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.507108] RSP 8801f88dfc58
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.508021] CR2: 0040
Jul 31 15:32:11 pmoody-x220 kernel: [ 108.516307] ---[ end trace
bcccee9a00e71a3b ]---
I can generate this oops by doing the following:
sudo /etc/init.d/auditd start ; sudo auditctl -D ; sudo auditctl -a
exit,always -F arch=b64 -S chmod -k oops ; gcc hello.c
The macro expansion in hello.c seems to be important.
Other bits of likely pertinent information: Running Ubuntu.
auditd/auditctl version 1.7.13-1ubuntu2 (ancient..), gcc version
4.4.3.
Please let me know if there's anything else I can provide (but please
cc me, I'm not subscribed to lkml).
Cheers,
peter
--
Peter Moody Google
Security Engineer pgp:0xC3410038
#include stdio.h
#define ME !
int main(void) {
printf(hello, world%s\n, ME);
return 0;
}
