Bug 152674 - Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Summary: Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Alias: None
Product: Fedora Legacy
Classification: Retired
Component: Package request (Show other bugs)
(Show other bugs)
Version: unspecified
Hardware: All Linux
Target Milestone: ---
Assignee: Fedora Legacy Bugs
QA Contact:
URL: http://isec.pl/vulnerabilities/isec-0...
Depends On:
TreeView+ depends on / blocked
Reported: 2004-02-18 10:08 UTC by Dominic Hargreaves
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description David Lawrence 2005-03-30 23:23:33 UTC
Another vulnerability has been found in the linux kernel - see URL for details.
I have built a kernel based on the redhat 9 erratum which is available from here:


I'll follow up with URLs for the binary RPMs when the build has finished :)

All signed by my pgp key 5178E2A5.
Let me know if you need any more input - only got involved with fedoralegacy in
the last week or so. The kernel also includes the i810 fix and another couple of
misc fixes.

I believe these will work on 7.2, 7.3 and 8.0; at least the last official update
was identical for all three releases[1]

[1] 8.0 actually had a different spec file with:

-%define release 28.7
+%define release 28.8

As the only difference. Shall I roll the equivalents for this fix?

------- Additional Comments From dom@earth.li 2004-02-18 06:12:04 ----

I was talking nonsense; the additional fix I was referring to was of course
r128, not i810.

------- Additional Comments From dom@earth.li 2004-02-18 07:31:01 ----

I have built binary packages for i386, i586, i686, athlon:


These are currently all untested except for
athlon/kernel-2.4.20-31.7.legacy.athlon.rpm which I've booted successfully.


------- Additional Comments From bugs.michael@gmx.net 2004-02-18 07:44:41 ----

Why 31.7 instead of 30.7? I see no difference compared with the rh9 30.9
erratum, see e.g. bug 1284 comment 3.

------- Additional Comments From dom@earth.li 2004-02-18 07:51:32 ----

Michael - The way I read
http://www.fedoralegacy.org/wiki/index.php/RpmVersioning what I did was correct,
but because the kernel versioning is a bit different from most it doesn't
entirely specify what was to be done. I reckoned that bumping that part of the
version number was safer than not.


------- Additional Comments From bugs.michael@gmx.net 2004-02-18 08:13:00 ----

I think you've misunderstood the document. Release 31.7 wins version comparison
with the rh9 erratum (30.9), which complicates the upgrade path from legacy
updated rh73 to up-to-date rh9.

------- Additional Comments From dom@earth.li 2004-02-18 08:19:31 ----

Okay - I hadn't considered that aspect of it.

Would it be helpful for me to build replacement source and/or binary RPMs with
fixed release numbers?

For my own internal purposes it doesn't matter since the boxes in question
aren't going to get their distro upgraded with redhat, but I'm happy to spare
the CPU time for it.

------- Additional Comments From bugs.michael@gmx.net 2004-02-18 08:39:53 ----

Well, as pointed out in comment 3, I've posted a patch earlier. I don't really
see the need in moving around 33 MiB huge src.rpms. Btw, changing %release is
something that can be done by someone close to the buildsystem.

------- Additional Comments From dom@earth.li 2004-02-18 08:49:40 ----

Okay, enough from me. Hadn't initially realised that the binary RPMs are always
built by "official" fedoralegacy people.

------- Additional Comments From arvand@sabetian.net 2004-02-18 12:56:53 ----

As Michael already pointed out, he has provided a patch at 
https://bugzilla.fedora.us/show_bug.cgi?id=1284 that "turns the rh9 erratum 
kernel 2.4.20-30.9 src.rpm into a rh73
kernel 2.4.20-30.7".

This would not only fix this vulnerability but the one at 
https://bugzilla.fedora.us/show_bug.cgi?id=1284 along with two others mentioned 
in the rh 9 advisory:

The Vicam USB driver in kernel versions prior to 2.4.25 does not use the 
copy_from_user function to access userspace, which crosses security 
boundaries.  The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2004-0075 to this issue.

Arjan van de Ven discovered a flaw in ncp_lookup() in ncpfs that could allow 
local privilege escalation.  ncpfs is only used to allow a system to mount 
volumes of NetWare servers or print to NetWare printers.  The Common 
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-
2004-0010 to this issue.

------- Additional Comments From jkeating@j2solutions.net 2004-02-18 14:07:21 ----

*** This bug has been marked as a duplicate of 1284 ***

------- Bug moved to this database by dkl@redhat.com 2005-03-30 18:23 -------

This bug previously known as bug 1302 at https://bugzilla.fedora.us/
Originally filed under the Fedora Legacy product and Package request component.

Unknown priority P2. Setting to default priority "normal".
Unknown platform PC. Setting to default platform "All".
Unknown severity major. Setting to default severity "normal".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.

Note You need to log in before you can comment on or make changes to this bug.