[rsbac] kernel oops accessing /dev/log

Vincent Danen vdanen at annvix.org
Thu Feb 9 02:15:50 CET 2006


* Vincent Danen <vdanen at annvix.org> [2006-02-08 16:03:43 -0700]:

Just for some testing purposed, I first eliminated the changes from the
openwall patch that touched socket.c, and still no dice.  Then I
eliminated the openwall patch completely, and it's still causing a
kernel oops.

I'm not sure what the problem here is, and am a bit lost on where to
look.  I'm going to try and compile with RSBAC with debugging enabled to
see if I can track this down further.

FWIW, I'm now seeing the problems in my vmware instance (did a fresh
upgrade of Annvix, upgraded rsbac-admin and installed the kernel and now
it's definitely showing up on a different system/config).

> Hi everyone.  I've got a bit of a problem with rsbac 1.2.5.1 and kernel
> 2.4.32.  When I try to "ls /dev/log" or run initlog (which a number of
> initscripts do), I'm getting a segfault of the application and a kernel
> oops printed to the screen:
> 
> 
>  <1>Unable to handle kernel NULL pointer dereference at virtual address
> 00000001
>  printing eip:
> c0146885
> *pde = 2f042067
> *pte = 00000000
> Oops: 0000
> CPU:    0
> EIP:    0010:[<c0146885>]    Not tainted
> EFLAGS: 00010202
> eax: 00000001   ebx: 0000000f   ecx: ef0c845c   edx: ef1c0f60
> esi: 00000000   edi: bffffa0c   ebp: ece63fbc   esp: ece63f40
> ds: 0018   es: 0018   ss: 0018
> Process initlog (pid: 827, stackpage=ece63000)
> Stack: f0bc2d99 ef1d7238 00000002 ef4cf800 ef1d7238 c0146b49 08051380
> 00000000 
>        ef195860 ece63f98 f0bbf987 ef1d7258 ef195840 08051380 00000292
> ef190901 
>        0000009e ef6ec2c0 ef195860 ef195840 ef1c0f60 effe9360 ef6ec2c0
> ef195840 
> Call Trace:    [<f0bc2d99>] [<c0146b49>] [<f0bbf987>] [<c0108bf3>]
> 
> Code: 83 38 01 0f 84 47 ff ff ff 8d 81 20 01 00 00 bb 0b 00 00 00 
> 
> 
> Now, syslog still seems to work properly.  Ie. these errors are being
> properly logged to syslog.  And if I do "logger mark" I get the
> appropriate:
> 
> Feb  8 15:15:57 cerberus vdanen: mark
> 
> in syslog.  So I'm not sure if rsbac is protecting /dev/log in some way
> that's preventing initlog from playing nice with it.  The strange thing
> is only one machine is exhibiting this behaviour (with or without
> rsbac_softmode).  I tested this same kernel (well, compiled with same
> options and patches) in vmware (one x86, another x86_64), and on an
> athlon (the one that fails) and an opteron, but the others work ok.  The
> rest of the system seems fine.
> 
> I have the kernel compiled with:
> 
> [root at cerberus etc]#  cat /proc/rsbac-info/active 
> Version: 1.2.5
> Mode: SOFTMODE
> Softmode: available
> Ind-Soft: available
> Switching: available for
> Module: REG  on
> Module: DAZ  on
> Module: FF   on
> Module: CAP  on
> Module: JAIL on
> Module: RES  on
> 
> (i just booted into softmode to see if I got the same behaviour).  The
> previous kernel did not do this (only change are the rsbac additions).
> The kernel is 2.4.32 with minimal patches; the only one that conflicted
> in any way with rsbac was the openwall kernel patch, but the rejected
> changesets were quite minimal and really shouldn't interfere, at least
> not for this.
> 
> Has anyone come across anything like this before?
> 
> -- 
> Annvix - Secure Linux Server: http://annvix.org/
> "lynx -source http://linsec.ca/vdanen.asc | gpg --import"
> {FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
> Wasting time like it was free...



> _______________________________________________
> rsbac mailing list
> rsbac at rsbac.org
> http://www.rsbac.org/mailman/listinfo/rsbac

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://www.rsbac.org/pipermail/rsbac/attachments/20060208/5fec981f/attachment.bin


More information about the rsbac mailing list