On 9 Dec 2005 at 2:49, JM wrote: > Linux praisenet 2.6.13-rsbac-rsbac #2 Mon Dec 5 17:06:35 CET 2005 i686 > Pentium > III (Katmai) GenuineIntel GNU/Linux
as far as PaX is concerned, 2.6.14 is the last 'supported' version, as in, i fix stuff only in there, and i'm sure i did do so since the 2.6.13 port was abandoned. so if you can give that a try and reproduce this, it'll help confirm/eliminate PaX bug at least. > I have Pax and some RSBAC modules compiled in, if requested I may attach my > configuration. > Should I send someone else this log too? Amon Ott probably would be interested as well. > Dec 9 02:35:01 hostname PREEMPT can you try without preempt? i never really audited PaX for such use, even if i think most of the code is not sensitive to it, it's better to leave it off. > Dec 9 02:35:01 hostname Call Trace: > Dec 9 02:35:01 hostname Code: 65 78 00 5f 5f 64 65 76 5f 67 65 74 5f 62 79 > 5f 6e 61 6d 65 00 5f 5f 64 65 76 5f 72 65 6d 6f 76 65 5f 70 61 63 6b 00 5f 5f > 73 6b <62> 5f 6c 69 6e 65 61 72 69 7a 65 00 64 65 76 5f 61 64 64 5f 70 this points to something royally hosed. the above 'code' resolves to a plain ascii string, eip fell into the middle of '__skb_linearize', hardly valid machine code ;-). but short of a valid stacktrace, it's hard to tell what the kernel was doing. maybe if you disabled module support and enabled KERNEXEC you'd get a better stacktrace, but that's just a guess. if you can reproduce it reliably, you could also just try PaX (on 2.6.14 as well) and RSBAC alone. -- [email protected] mailing list
