Bug 107002

Summary:	Exec-stackable glibc does not depend on Exec-stackable kernel
Product:	[Retired] Red Hat Raw Hide	Reporter:	Nicolas Mailhot <nicolas.mailhot>
Component:	glibc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED RAWHIDE	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	high
Version:	1.0	CC:	fweimer
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-10-16 14:42:23 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nicolas Mailhot 2003-10-14 10:58:20 UTC

Today a glibc that depends on an exec-stackable kernel leaked in Rawhide.

The problem is this package does not depend on a kernel package that is
exec-stack enabled.

As a result a package manager will update the system and glibc without updating
the kernel (most package managers do not update kernels automatically by default
since this is deemed a dangerous operation).

After the operation most apps wont execute anymore since they need the kernel
facilities and the kernel was not updated. This includes rpm (in beecrypt). You
can not even download the latest rawhide kernel and install with rpm to fix the
mess.

Game over.

Comment 1 Jakub Jelinek 2003-10-16 14:42:23 UTC

But it does not depend on kernel with exec-shield.
It depends on either kernel without exec-shield, or with non-buggy exec-shield
support. Furthermore, dependencies on running kernel (as opposed to installed)
are not expressible in rpm.
To my knowledge, the buggy kernels (with non-executable stack, but without MAYEXEC
flag on it, such that it cannot be made executable) have never been released
in any final distro by us; beta testing includes such risks.
You should be able to workaround this by disabling exec-shield
(echo 0 > /proc/sys/kernel/exec-shield), upgrading kernel and rebooting.

Comment 2 Nicolas Mailhot 2003-10-16 15:11:09 UTC

Ok, fair enough.