Messages in this thread | | | Date | Mon, 16 Jun 2014 20:36:26 +0200 | From | Toralf Förster <> | Subject | Re: 3.15: kernel BUG at kernel/auditsc.c:1525! |
| |
On 06/16/2014 08:24 PM, Andy Lutomirski wrote: > On Mon, Jun 16, 2014 at 11:21 AM, Toralf Förster <toralf.foerster@gmx.de> wrote: >> On 06/16/2014 08:15 PM, Andy Lutomirski wrote: >>> On Mon, Jun 16, 2014 at 10:59 AM, Toralf Förster <toralf.foerster@gmx.de> wrote: >>>> On 06/16/2014 07:50 PM, Andy Lutomirski wrote: >>>>> cc: eparis. This might be a new audit bug. >>>>> >>>>> On Mon, Jun 16, 2014 at 10:36 AM, Toralf Förster <toralf.foerster@gmx.de> wrote: >>>>>> On 06/16/2014 07:32 PM, Andy Lutomirski wrote: >>>>>>> On Mon, Jun 16, 2014 at 10:29 AM, Richard Weinberger <richard@nod.at> wrote: >>>>>>>> Am 16.06.2014 19:25, schrieb Andy Lutomirski: >>>>>>>>> On Mon, Jun 16, 2014 at 10:21 AM, Richard Weinberger >>>>>>>>> <richard.weinberger@gmail.com> wrote: >>>>>>>>>> On Mon, Jun 16, 2014 at 6:33 PM, Toralf Förster <toralf.foerster@gmx.de> wrote: >>>>>>>>>>> $ cat syscall.c >>>>>>>>>>> #include <unistd.h> >>>>>>>>>>> #include <sys/syscall.h> >>>>>>>>>>> int main(){return syscall(1000)!=-1;} >>>>>>>>> >>>>>>>>> What architecture are you building for? On i386 and x86_64, 1000 >>>>>>>>> shouldn't be big enough to trigger this. >>>>>>>> >>>>>>>> Toralf, is this an UML kernel? >>>>>>>> >>>>>>> >>>>>>> I'm also interested in the userspace architecture. If it's x32 >>>>>>> userspace, then I'm not surprised that there's a problem. >>>>>> >>>>>> It is a x86 system (ThinkPad T420) - not x32. >>>>> >>>>> I don't think this is CVE-2014-3917. It looks like you're hitting this BUG: >>>>> >>>>> BUG_ON(context->in_syscall || context->name_count); >>>>> >>>>> Can you send the output of: >>>>> >>>>> auditctl -l [run as root] >>>>> >>>>> and >>>>> >>>>> dmesg |grep audit >>>>> >>>>> Are you using ptrace or anything like that (e.g. strace) when you >>>>> trigger this? Are you using a funny glibc version? Do you have >>>>> selinux or something like that enabled? >>>>> >>>>> --Andy >>>>> >>>> n22 ~ # auditctl -l >>>> LIST_RULES: exit,never arch=1073741827 (0x40000003) syscall=read,write,open,close,brk,fcntl,dup2,mmap,munmap,stat,fstat,nanosleep,rt_sigaction >>>> >>>> >>>> no ptrace/strace/SELinux, this is a stable x86 Gentoo Linux, glibc is 2.17, unstable are just KDE + Co. >>>> >>>> (@Richard: no. it is not an UML guest, I just stumbled over this while I tried to upgrade an unstable ~x86 Gentoo UML image using chroot) >>>> >>>> The trigger is just given by that C one-liner and kernel 3.15 (erm, I did not checked, if 3.14.x hit its too) >>> >>> At the very least, it looks like sysret_audit can result in invoking >>> the audit exit hook twice. That's not what's causing this, but it >>> still looks fishy. >>> >>> Toralf, can you run your test program under strace, post the output, >>> and see whether it still crashes? There's some chance that strace >>> will "fix" it, since strace causes a different set of hooks to run. >>> >> tfoerste@n22 ~/tmp $ cat syscall.c >> #include <unistd.h> >> #include <sys/syscall.h> >> int main(){return syscall(1000)!=-1;} >> >> tfoerste@n22 ~/tmp $ gcc strcmp.c && strace ./a.out >> execve("./a.out", ["./a.out"], [/* 75 vars */]) = 0 >> brk(0) = 0x85f3000 >> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7750000 >> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) >> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 >> fstat64(3, {st_mode=S_IFREG|0644, st_size=164108, ...}) = 0 >> mmap2(NULL, 164108, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7727000 >> close(3) = 0 >> open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 >> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \316\1\0004\0\0\0"..., 512) = 512 >> fstat64(3, {st_mode=S_IFREG|0755, st_size=1750448, ...}) = 0 >> mmap2(NULL, 1759980, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7579000 >> mmap2(0xb7721000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a8000) = 0xb7721000 >> mmap2(0xb7724000, 10988, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7724000 >> close(3) = 0 >> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7578000 >> set_thread_area({entry_number:-1 -> 6, base_addr:0xb75786c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 >> mprotect(0xb7721000, 8192, PROT_READ) = 0 >> mprotect(0x8049000, 4096, PROT_READ) = 0 >> mprotect(0xb7774000, 4096, PROT_READ) = 0 >> munmap(0xb7727000, 164108) = 0 >> fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 5), ...}) = 0 >> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb774f000 >> write(1, "1\n", 21 >> ) = 2 > > Does this mean it didn't OOPS? And where's the write(1, "1\n", 2) > coming from? Are you sure you straced the right thing? > > --Andy >
Ick - sry ,
here is the trace of the syscall.c, but as you expected, no BUG in syslog if I use strace :
tfoerste@n22 ~/tmp $ gcc syscall.c && strace ./a.out execve("./a.out", ["./a.out"], [/* 75 vars */]) = 0 brk(0) = 0x8d75000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb76ee000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=164108, ...}) = 0 mmap2(NULL, 164108, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb76c5000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \316\1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1750448, ...}) = 0 mmap2(NULL, 1759980, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7517000 mmap2(0xb76bf000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a8000) = 0xb76bf000 mmap2(0xb76c2000, 10988, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76c2000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7516000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb75166c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb76bf000, 8192, PROT_READ) = 0 mprotect(0x8049000, 4096, PROT_READ) = 0 mprotect(0xb7712000, 4096, PROT_READ) = 0 munmap(0xb76c5000, 164108) = 0 syscall_1000(0, 0x8048469, 0xb76c1000, 0x8048460, 0, 0) = -1 (errno 38) exit_group(0) = ? +++ exited with 0 +++
-- Toralf
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |