kdeinit causes scheduling while atomic

kdeinit causes scheduling while atomic

[Will Simoneau]

[-- Attachment #1: Type: text/plain, Size: 3001 bytes --]

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?

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)

System is running Gentoo, the compiler is gcc 3.4.6 with pie & ssp
although those features are turned off when compiling a kernel by the
specs file. Userland is compiled with -fstack-protector, and I am using
SEGMEXEC for userland NX support.

I have two different traces and some PaX output, here they all are:
---cut here---
BUG: scheduling while atomic: kdeinit/0x00000002/31816
 <c0345c9c> schedule+0x53e/0x674  <c0346657> schedule_timeout+0x4d/0x9a
 <c0152a12> process_timeout+0x0/0x5  <c0145954> sched_fork+0x51/0x86
 <c01483aa> copy_process+0x614/0xdea  <c0148c66> do_fork+0x75/0x1b2
 <c019864d> vfs_write+0xec/0x16e  <c012dbf5> sys_clone+0x32/0x36
 <c012f057> syscall_call+0x7/0xb  <c012007b> init_script_binfmt+0x6/0xa
---end cut----

---cut here---
BUG: scheduling while atomic: kdeinit/0x00000002/31816
 <c0345c9c> schedule+0x53e/0x674  <c0346657> schedule_timeout+0x4d/0x9a
 <c0152a12> process_timeout+0x0/0x5  <c0145954> sched_fork+0x51/0x86
 <c01483aa> copy_process+0x614/0xdea  <c0148c66> do_fork+0x75/0x1b2
 <c012dbf5> sys_clone+0x32/0x36  <c012f057> syscall_call+0x7/0xb
 <c013007b> irq_entries_start+0xecb/0xef0 
---end cut----

---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?

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.

In the terminal where I start konqueror I see this (when PaX does the
killing):

---cut here---
Try to load libthai dynamically...
Error, can't load libthai...
zsh: killed     konqueror
---end cut----

... which seems to be an old unsolved bug in qt.

Do I or anybody else have any hope of tracking this down? It almost
sounds like an interaction of multiple bugs.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [grsec] kdeinit causes scheduling while atomic

[Will Simoneau]

[-- Attachment #1: Type: text/plain, Size: 4037 bytes --]

On 14:08 Sun 23 Jul     , pageexec@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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]