linux-kernel - Re: [grsec] kdeinit causes scheduling while atomic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20060723210039.GC30515@ele.uri.edu>
Date:	Sun, 23 Jul 2006 17:00:39 -0400
From:	Will Simoneau <simoneau@....uri.edu>
To:	pageexec@...email.hu
Cc:	grsecurity@...ecurity.net, linux-kernel@...r.kernel.org
Subject: Re: [grsec] kdeinit causes scheduling while atomic

On 14:08 Sun 23 Jul     , pageexec@...email.hu wrote:
> On 18 Jul 2006 at 9:58, Will Simoneau wrote:
> > A scheduling while atomic just started showing up in the kernel log on
> > my machine, which unfortunately is running an odd combination of
> > non-vanilla patches. Maybe someone who knows at least some of the code
> > can give me some hints tracking this down? Or maybe the grsecurity folks
> > have an idea?
> 
> given that probably neither side is familiar with  the other's patches,
> you should try to reproduce this with only one patch first. in the meantime,
> it'd help to find out what gets called at copy_process+0x614/0xdea, there's
> probably a 'call' insn around copy_process+60f, you can use objdump to find
> out who the target is.

objdump -d:

   c014838a:   be 00 f0 ff ff          mov    $0xfffff000,%esi
   c014838f:   8b bb a0 00 00 00       mov    0xa0(%ebx),%edi
   c0148395:   21 e6                   and    %esp,%esi
   c0148397:   8b 06                   mov    (%esi),%eax
   c0148399:   85 ff                   test   %edi,%edi
   c014839b:   0f b7 40 2c             movzwl 0x2c(%eax),%eax
   c014839f:   66 89 43 2c             mov    %ax,0x2c(%ebx)
   c01483a3:   74 51                   je     c01483f6 <copy_process+0x660>
-> c01483a5:   e8 a7 ab 0f 00          call   c0242f51 <gr_handle_brute_check>
   c01483aa:   8b 83 ac 00 00 00       mov    0xac(%ebx),%eax
   c01483b0:   05 b0 00 00 00          add    $0xb0,%eax
   c01483b5:   8b 4c 24 0c             mov    0xc(%esp),%ecx

> 
> > Patches applied on top of 2.6.17.6:
> > grsecurity-2.1.9-2.6.17.4-200607120947
> > suspend2-2.2.7-for-2.6.17 (without 9920-linus-basic-trace - that plus
> > grsecurity gives rejects on vmlinux.lds.S)
> 
> from what i see, it's a trivial reject, you can apply it by hand after RODATA.
> 
> > ---cut here---
> > PAX: execution attempt in: <NULL>, 00000000-00000000 00000000
> > PAX: terminating task: /usr/kde/3.5/bin/konqueror(konqueror):21177, uid/euid: 1000/1000, PC: 00000010, SP: 5953cf80
> > PAX: bytes at PC: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 
> > PAX: bytes at SP-4: 00000010 00000003 5953cfb0 00000000 0000000a 0000001c 40488ef8 0000001d 5618e6e0 40083d30 00000000 00000003 55efdb83 40189c00 56108d92 56b09377 5618e6e0 5953d000 00000006 404eadb8 55f2bef8 
> > ---end cut----
> > 
> > Call of a null function pointer?
> 
> it's interesting that at esp-4 you have 0x10, which happens to be the
> faulting eip value as well. this can occur if the fault occured not
> due to a 'call' but rather a 'retn' insn, that is, a function was trying
> to return to its caller, but the return address got overwritten on the
> stack. now whether that happened due to some programming error or a
> gcc/ssp bug is a good question. i'd first try to recompile it (and all
> related libraries!) w/o ssp, it's known to have code generation bugs for
> c++ code. if that cures the problem, you should enter it into the gentoo
> bugzilla.

It's caused by qt, with -fstack-protector(-all?) enabled. Version is
x11-libs/qt-3.3.6-r1 from portage. Without ssp, going to wikipedia in
konqueror works fine. Will file at bugs.gentoo.org when I get a chance.

> 
> > Sometimes konqueror is killed by PaX, sometimes it dies on its own (I
> > think with a segfault). I can reproduce this 100% of the time by firing
> > up Konqueror and going to www.wikipedia.org, just before the front page
> > loads the window dissapears and leave those traces behind. Other sites
> > seem to work fine. The process either segfaults or is killed by PaX
> > immediately after causing the scheduling while atomic.
> 
> you mean, the first mentioned schedule BUG triggered in kdeinit is related
> to this crash in konqueror? or are you getting a schedule BUG in konqueror
> as well? in any case, eliminating one variable at a time (like ssp) should
> help you nail the bug(s) down.
> 

I'm not sure what's happening with the scheduling while atomic now.

Content of type "application/pgp-signature" skipped