[grsec] kdeinit causes scheduling while atomic
Will Simoneau
simoneau at ele.uri.edu
Sun Jul 23 17:00:39 EDT 2006
On 14:08 Sun 23 Jul , pageexec at freemail.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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://grsecurity.net/pipermail/grsecurity/attachments/20060723/e7768b4b/attachment.pgp
More information about the grsecurity
mailing list