[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#321718: Upgrade caused many libs to complain about "executable stack"

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

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.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: