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

Bug#536148: marked as done (linux-2.6: [regression] CVE-2009-1758 fixed in testing, but not in unstable)

Your message dated Wed, 08 Jul 2009 00:44:11 +0100
with message-id <1247010251.21924.17.camel@deadeye>
and subject line Re: Bug#536148: linux-2.6: [regression] CVE-2009-1758 fixed in testing, but not in unstable
has caused the Debian Bug report #536148,
regarding linux-2.6: [regression] CVE-2009-1758 fixed in testing, but not in unstable
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
536148: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536148
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-2.6
Version: 2.6.30-1
Severity: grave
Tags: security
Justification: user security hole

Hello again Debian kernel team!

According to the security tracker [1], CVE-2009-1758 is fixed in
testing, but not in unstable.
It's fixed in testing because it was fixed in a stable (lenny) point
release, and stable packages updated in a point release are
automatically migrated to testing, whenever the version in testing
happens to be older than the updated stable one.

[1] http://security-tracker.debian.net/tracker/CVE-2009-1758

Having a fixed package in testing is great, but of course it also means
that the vulnerability should be fixed in unstable before the package
migrates from unstable to testing, or otherwise a regression will
happen!

As part of a triage effort [2], I personally tried to understand whether
CVE-2009-1758 is already fixed in linux-2.6/2.6.30-1, but I failed [3].

[2] see the following subthread for further details:
    http://lists.debian.org/debian-security-tracker/2009/07/msg00007.html
[3] see especially this message:
    http://lists.debian.org/debian-security-tracker/2009/07/msg00024.html

Please note that I didn't actually test linux-2.6/2.6.30-1 against
the vulnerability: I just searched for the link to the supposed fix in
the mitre CVE page and with the intention to take a look at the relevant
files in linux-2.6_2.6.30.orig.tar.gz, in order to see whether they
included the modifications...


I am filing this bug report, in order to make sure CVE-2009-1758 is
fixed in unstable, before linux-2.6 migrates to testing.

Please check whether CVE-2009-1758 is fixed in linux-2.6/2.6.30-1:
if the fix is already included, then this bug report may be safely
closed.
On the other hand, if linux-2.6/2.6.30-1 is vulnerable, then please
apply the fix that was used [4] to prepare linux-2.6/2.6.26-15lenny3
and upload a new Debian revision (linux-2.6/2.6.30-2) that fixes
the vulnerability.

[4] see http://security-tracker.debian.net/tracker/DSA-1809-1


Once again, thanks for all the great job you're doing on the kernel
packages!

--- End Message ---
--- Begin Message --- 
Version 2.6.28-1

On Tue, 2009-07-07 at 23:11 +0200, Francesco Poli (t1000) wrote: 
> Package: linux-2.6
> Version: 2.6.30-1
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> Hello again Debian kernel team!
> 
> According to the security tracker [1], CVE-2009-1758 is fixed in
> testing, but not in unstable.
[...]

The domU code accepted into Linux appears to have always included a
similar check[*].  Only the dom0 code had this bug, and we do not build
dom0 kernels any more as the patch is not maintainable.

* From arch/xen/xen-asm_32.S:

        /*
         * Paranoia: Make sure we're really coming from kernel space.
         * One could imagine a case where userspace jumps into the
         * critical range address, but just before the CPU delivers a
         * GP, it decides to deliver an interrupt instead.  Unlikely?
         * Definitely.  Easy to avoid?  Yes.  The Intel documents
         * explicitly say that the reported EIP for a bad jump is the
         * jump instruction itself, not the destination, but some
         * virtual environments get this wrong.
         */
        movl PT_CS(%esp), %ecx
        andl $SEGMENT_RPL_MASK, %ecx
        cmpl $USER_RPL, %ecx
        je 2f

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
                                                            - Robert Coveyou

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: