On Sun, Aug 07, 2005 at 05:42:03PM -0400, Joe Mason wrote: > > So, even though running etch/sid against a woody kernel is indeed not > > supported, that doesn't seem the issue here. > > Instead, Joe, it looks like you *are* running a kernel on this machine that > > has grsec enabled, even if you don't know how it got there. It would be > > helpful to have more complete information from the actual system in question > > to confirm this, though. > jnc@gate:/boot$ uname -a > Linux gate 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 GNU/Linux > jnc@gate:/boot$ dpkg -l|grep kern > ii iptables 1.3.3-1 Linux kernel 2.4+ > iptables administration to > ii linux-kernel-headers 2.6.13+0rc3-1 Linux Kernel > Headers for development > rc nfs-kernel-server 1.0-2woody3 Kernel NFS server > support > jnc@gate:/boot$ ls /boot > System.map-2.4.18-bf2.4 coffee.bmp debianlilo.bmp sid.bmp > boot.0300 config-2.4.18-bf2.4 map > vmlinuz-2.4.18-bf2.4 > boot.b debian.bmp sarge.bmp > I can confirm vmlinuz-2.4.18-bf2.4 is the kernel being booted. Ok, that brings us back to the point of the current glibc needing to raise its minimum version number for kernel compatibility. > This kernel was compiled on another machine and installed by hand > instead of going through kpkg. Unfortunately I don't have the sources > anymore, but I don't recall installing any patches, which I understand > would be necessary for "grsecurity". I did spend a while playing with > various kernel patches on another machine, so it's possible I'm mixed up > and installed that kernel here, but I'd figured out kpkg by that time so > I probably would have a kernel package if I'd done that. Sure. It seems there's been another report of this problem with a 2.4.18 kernel, and I guess the origin of the incompatibility has also been identified: 08:47 <waldi> mprotect(0xbffff000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid argument) 08:47 <waldi> mprotect(0xbfff8000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EFAULT (Bad address) 08:55 <waldi> PROT_GROWSDOWN seems to be new in 2.4.21 and 2.5 I'm not sure there were ever grsec packages available for 2.4.18 anyway, but it seems irrelevant after all. > > The last bug, I'm leaving assigned to glibc, since that is the package whose > > behavior change triggered these reports. Of course, this is simply a case > > of glibc bailing on error from mprotect() rather than silently ignoring the > > permission issues, so I imagine the glibc maintainers won't do anything with > > this bug except close it... > Aha, so my kernel has been "broken" for ages but libc was ignoring it. > Wonderful. I'll install a new one tomorrow, and back up my /boot > directory in case anyone needs to take a look at the current one. Ok. I think this bug should be trackable from here without recourse to your /boot, but please report back if for some reason upgrading the kernel doesn't fix the problem for you. Cheers, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature