Bug 113227 (CVE-2005-4095)

Created attachment 47712 [details]
xorg-overflow.patch

CAN-2005-2495

cc joe and dhessing, who received this from SUN via JDS/SLEC too.  

CRD: 2005-09-08 1400UTC

Please make sure to cc Egbert on future X11 security bugs, else he will 
not be able to access them or work on them 

There is another version of this patch in above ticket and this seems to be more
complete. However I don't fully understand it yet as I don't see why the
paddedWidth is devided by 4.
I will investigate.

It's not yet fully clear what the right fix for this would be. So far I cannot
recommed any patch for 10.0.

Ok. Thanks for checking!

Resent-Date: 7 Sep 2005 06:41:01 -0000
Subject: Re: Integer overflow in pixmap allocation code
From: Daniel Stone <daniel@fooishbar.org>
To: Paul M Anderson <pma@fc.hp.com>
Cc: Soeren Sandmann <sandmann@redhat.com>, xorg_security@x.org
Date: Wed, 07 Sep 2005 16:42:11 +1000
Resent-Message-ID: <vEVfCD.A.y7.9toHDB@mailman>
Resent-To: xorg_security@opengroup.org
Resent-From: xorg_security@opengroup.org
Resent-Sender: xorg_security-request@opengroup.org

On Wed, 2005-09-07 at 00:36 -0600, Paul M Anderson wrote:
> ----- Original Message -----
> From: "Soeren Sandmann" <sandmann@redhat.com>
> To: <xorg_security@x.org>
> Sent: Thursday, August 25, 2005 10:24 AM
> Subject: Integer overflow in pixmap allocation code
>
> > Does anybody have a suggestion for an embargo date? My suggestion would
> > be two weeks from
> > now, ie., Thursday, Sep. 8. That should be plenty of time to get this
> > patch uploaded and an
> > announcement sent out.
>
> Would anyone be against pushing the embargo date out at all?  Or, are
> people ready/anxious to go on the 8th?

Debian/Ubuntu at least are ready to go for the 8th (or wasn't it listed
as the 9th?), and I believe Red Hat are also.

Thomas, please inform these guys about Egbert's concerns. I'm really not
interested in doing this security update twice for

  9.0
  9.1
  9.2
  9.3
  10.0
  SLES9
  SLES9-SP3

It's really much work, for which I currently don't have time anyway ...

It's from the xorg_security list, Egbert is subscribed to it too and will see it
/ should already have seen it. But I'll give them a little stopper and let
Egbert explain the details later. :)

Subject: Re: Integer overflow in pixmap allocation code
From: Daniel Stone <daniel@fooishbar.org>
To: Thomas Biege <thomas@suse.de>
Cc: Paul M Anderson <pma@fc.hp.com>, Soeren Sandmann <sandmann@redhat.com>,
        xorg_security@x.org
Date: Wed, 07 Sep 2005 17:54:03 +1000

On Wed, 2005-09-07 at 09:49 +0200, Thomas Biege wrote:
> On Wed, Sep 07, 2005 at 04:42:11PM +1000, Daniel Stone wrote:
> > On Wed, 2005-09-07 at 00:36 -0600, Paul M Anderson wrote:
> > > Would anyone be against pushing the embargo date out at all?  Or, are
> > > people ready/anxious to go on the 8th?
> >
> > Debian/Ubuntu at least are ready to go for the 8th (or wasn't it listed
> > as the 9th?), and I believe Red Hat are also.
>
> Egbert Eich has some concerns regarding the current patch. I think he will
> explain the details later...

How much later?  Embargo is only 36 hours away, so if we need to delay
it, sooner is better than later.
~

> It's from the xorg_security list, Egbert is subscribed to it too and will see it
> / should already have seen it. But I'll give them a little stopper and let
> Egbert explain the details later. :)

Yes, I am subscribed to this list but I don't seem to receive any post from it
any more. 
I would like to see the final version of this patch. I've seen two different
patches which do different tests (the one here and the one in freedesktop's
bugzilla.) Right off hand I would favor the one here. 

Created attachment 49024 [details]
XFree86-4.3.0-security-CAN-2005-2495.patch

Resent-Date: 26 Aug 2005 20:24:12 -0000
Date: Fri, 26 Aug 2005 16:24:02 -0400
From: Soeren Sandmann <sandmann@redhat.com>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
To: Kevin E Martin <kem@redhat.com>
Cc: xorg_security@x.org
Subject: Re: [Fwd: Re: [vendor-sec] [sandmann@redhat.com: Possible X security
 bug]]
Resent-Message-ID: <5LxX5D.A.KPC.sp3DDB@mailman>
Resent-To: xorg_security@opengroup.org
Resent-From: xorg_security@opengroup.org
Resent-Sender: xorg_security-request@opengroup.org

[-- Anhang #1 --]
[-- Typ: text/plain, Kodierung: 8bit, GröÃe: 0,8K --]

Kevin E Martin wrote:

>FYI, Soeren is working on an updated patch to fix some additional cases,
>which he will forward to this list after testing.
>
>When it's ready, I would like to ask everyone here to review it to make
>sure that the potential security issues have been adequately covered.
>Also, if others have similar patches to fix this vulnerability, please
>let us know.
>
Here is the updated patch, which should take care of the oversight
that paddedWidth is in bytes, not pixels. And in addition also make sure
that
the final size, including pixmap privates, isn't bigger than what fits in a
size_t. Both of these were pointed out by Kevin.

Note that in the bitmap cases, the paddedwidth is still multiplied with
the depth. Not sure what that's about. In those cases I have inserted a
check check that the depth is <= 4.
SÞren

[-- Anhang #2: XFree86-4.3.0-security-CAN-2005-2495.patch --]
[-- Typ: text/x-patch, Kodierung: 7bit, GröÃe: 8,9K --]


Date: Mon, 29 Aug 2005 22:02:57 +0200
From: Matthieu Herrb <matthieu.herrb@laas.fr>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050819)
To: Soeren Sandmann <sandmann@redhat.com>
Cc: Kevin E Martin <kem@redhat.com>, xorg_security@x.org
Subject: Re: [Fwd: Re: [vendor-sec] [sandmann@redhat.com: Possible X security
 bug]]
Resent-Message-ID: <5lYmEC.A.h8C.qF3EDB@mailman>
Resent-To: xorg_security@opengroup.org
Resent-From: xorg_security@opengroup.org
Resent-Sender: xorg_security-request@opengroup.org

Soeren Sandmann wrote:
>Kevin E Martin wrote:
>
>>FYI, Soeren is working on an updated patch to fix some additional cases,
>>which he will forward to this list after testing.
>>
>>When it's ready, I would like to ask everyone here to review it to make
>>sure that the potential security issues have been adequately covered.
>>Also, if others have similar patches to fix this vulnerability, please
>>let us know.
>>
>Here is the updated patch, which should take care of the oversight
>that paddedWidth is in bytes, not pixels. And in addition also make sure
>that
>the final size, including pixmap privates, isn't bigger than what fits in a
>size_t. Both of these were pointed out by Kevin.
>

I've been looking at this patch, and I'm running with it since friday.
The patch looks ok to me, and I've seen negative effects for now.
--
Matthieu Herrb

This doesn't help me much. Would be please attach the patch?

It is attached, just the first line of comment #14. :)

All the attachment comments made it a bit chaotic...

Resent-Date: 7 Sep 2005 14:22:31 -0000
Date: Wed, 07 Sep 2005 10:19:40 -0400
From: Soeren Sandmann <sandmann@redhat.com>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
To: Daniel Stone <daniel@fooishbar.org>
Cc: Thomas Biege <thomas@suse.de>, Paul M Anderson <pma@fc.hp.com>,
        xorg_security@x.org
Subject: Re: Integer overflow in pixmap allocation code
Resent-Message-ID: <XFFGpC.A.1vD.nevHDB@mailman>
Resent-To: xorg_security@opengroup.org
Resent-From: xorg_security@opengroup.org
Resent-Sender: xorg_security-request@opengroup.org

Daniel Stone wrote:

>Egbert's comment on the bug:
>
>
>>+    if (paddedWidth / 4 > 32767 || height > 32767)
>>+     return NullPixmap;
>>    datasize = height * paddedWidth;
>>
>>I'm trying to understand why we are dividing paddedWidth by 4.
>>A paddedWidth of 32766*4 and a height of 32766 would be legal.
>>datasize is int. 32766 * 32766*4 is 0xfff80010 - which is more than you
>>can fit
>>into an int.
>>
Yes, 0xfff80010 is more than you can fit in an int, but it does fit in a
size_t (which is unsigned), so no overflow happens. Note that the patch
also has:

-    int datasize;
-    int paddedWidth;
+    size_t datasize;
+    size_t paddedWidth;

>Where does the 4 come from?

The maximum number bytes for pixmap depth.

>Also I don't see why we check for depth > 4 for ilbm and afb. Shouldn't
>this be
>caught elsewhere?

Yes, the < 4 should be caught elsewhere, but those checks don't do any harm.

>Based on this, I propose extending the embargo indefinitely until these
>issues are sorted out.
>
>
I don't see any reason to do that.

SÞren

VU#102441
CAN-2005-4095

To: vendor-sec@lst.de
Cc: sandmann@redhat.com
Subject: Re: [vendor-sec] [sandmann@redhat.com: Possible X security bug]
From: Joshua Bressers <bressers@redhat.com>
Errors-To: vendor-sec-admin@lst.de
Date: Wed, 07 Sep 2005 16:17:48 -0400

> This issue is CAN-2005-2495.
>
> Soeren,
>
> Can you make sure upstream is aware of this for the advisory.
>
> --
>     JB
>
> On Thu, Aug 25, 2005 at 02:43:34PM -0400, Josh Bressers wrote:
> > This issue was brought to our attention by one of our xorg developers.  I'm
> > attaching the patch.  The bug referenced is no longer public, and for the
> > short period of time it was, didn't provide any information to suggest that
> > issue was anything but a simple crash.
> >
> > The current embargo is 2005-09-08 1400UTC

Upstream has requested that the emabargo be moved to 2005-09-12 1400UTC.

If this isn't going to work for anyone, please let us know ASAP.

Thanks.

--
    JB

Created attachment 49158 [details]
Latest patch?

Date: Wed, 7 Sep 2005 17:27:22 -0400
To: SuSE Security Team <security@suse.de>
From: CERT Coordination Center <cert@cert.org>
Cc: CERT Coordination Center <cert@cert.org>
Subject: [security@suse.de] Vulnerability Report: VU#102441 - suse
Errors-To: security-bounces+thomas=suse.de@suse.de

Hello folks,

We have received a report of a security vulnerability in a product that may be
relevant to you.  We have assigned an internal reference number (VU#102441) to
this report and it is included in the subject line of this e-mail message.
This unique, random number will help us track correspondence and coordinate
our activities. We would appreciate your including it in the subject line of
future correspondence about this issue.  The CVE ID is CAN-2005-4095.

The X.Org X server is vulnerable to an undisclosed flaw which may allow
arbitrary code execution by local authenticated users.	The flaw is due to be
disclosed tomorrow, 8 September 2005.  We recommend that concerned parties
contact X.Org directly for more information on the vulnerability if so
desired.

This flaw may also be present in related code, such the XFree86 X server
code base.  We recommend that all parties ensure that any related applications
in use are not affected.

We have included the original, confidential vulnerability report.  Please do
not redistribute this information.  Please also note that this information,
including all patches and material, is not considered official or final at
this point.

If you have any questions or concerns, please don't hesitate to let us know.

Thanks,
Ken

=== BEGIN CONFIDENTIAL VULNERABILITY REPORT ===

Please describe the vulnerability.
- ----------------------------------

There are several places in the X server pixmap allocation code where an
integer overflow can cause the X server to allocate significantly less
memory than necessary for a pixmap. This potentially allows a malicious
client to read and write all of the X server's address space using the X
protocol requests PolyPoint and GetImage.


What is the impact of this vulnerability?
- -----------------------------------------
 (For example: local user can gain root/privileged access, intruders
  can create root-owned files, denial of service attack,  etc.)

   a) What is the specific impact:

	Malicious client can cause X server to execute arbitrary code.
	This is a priority elevation since the X server typically runs
	as the superuser.

   b) How would you envision it being used in an attack scenario:

	1. Client would first allocate a pixmap, then use PolyPoint to
	   write machine code into this pixmap.

	2. Client then allocates a second pixmap with a size of 2^32 + 3,
	   causing an integer overflow that makes the X server allocate
	   only 4 bytes of memory.

	3. Client the uses GetImage on the second pixmap to read anywhere
	   in the X server address space, looking for the runtime stack of
	   the X server.

	4. Once the client has found the runtime stack it uses PolyPoint to
	   rewrite a return address to point to the first pixmap.

	5. X server returns into code written by the client.

To your knowledge is the vulnerability currently being exploited?
- -----------------------------------------------------------------
	no

Are you aware of any workarounds and/or fixes for this vulnerability?
- ---------------------------------------------------------------------
	[yes/no] (If you have a workaround or are aware of patches
	      please include the information here.)


This patch is believed to fix the problem.
OTHER INFORMATION
===========================================================================
Is there anything else you would like to tell us?

The embargo date for this bug is Thursday, Sep. 8th.

The CVE ID is:	 CAN-2005-4095
=== END CONFIDENTIAL VULNERABILITY REPORT ===


--
Ken MacInnis
__________________________________________________________
CERT(R) Coordination Center    |	     cert@cert.org
Software Engineering Institute | Hotline : +1 412.268.7090
Carnegie Mellon University     |     FAX : +1 412.268.6989
Pittsburgh, PA 15213-3890      |      http://www.cert.org/
==========================================================
     CERT and CERT Coordination Center are registered
	 in the U.S. Patent and Trademark Office.

    The Software Engineering Institute is sponsored by
	      the U.S. Department of Defense.

Egbert just told me, that this issue is still being discussed in X.Org Bugzilla.
Unfortunately I don't have access to X.Org Bug #594.

Sorry for the confusion. It's the patch attached by Thomas as #49158.

Created attachment 49358 [details]
fixed malformed attachment #49158 [details]

applied patch for 10.0-RC2.

Could you please tell me, when the embargo is over (should be today) and attach
the official patch, which comes /is referenced with the announcement? I plan to
do the updates for older releases tomorrow

  9.0
  9.1
  9.2
  9.3
  10.0
  SLES9
  SLES9-SP3

Monday, sep. 12, 14.00 UTC, so 1600 here AFAIK

Ok. Thanks. And don't forget to attach the official patch. :-)

The latest patch attached is the latest I have.

Sure, but I hope that there will be an official patch when this issue goes public?

I do not know.. maybe Egbert knows more.

Maintenance-Tracker-2234

From: SWAMP <swamp@suse.de>
To: sndirsch@suse.de
Subject: Maintenance-Tracker-2234: XFree86,xorg-x11 Patchinfo
Date: Mon, 12 Sep 2005 15:10:09 +0200 (CEST)

Hello ,
there is a new SM-Issue regarding XFree86,xorg-x11.
Bugzilla: #113227

Summary: integer overflow in pixmap handling
Issue was started by: thomas
Description:
This update fixes an integer overflow in the pixmap handling. (CAN-2005-2495)
An attacker may be able to exploit this bug to execute code remotely.

Please submit the fixed package(s) to:
/work/src/done/<Distributions>/<packages>
You have to submit one or more patchinfos to /work/src/done/PATCHINFO.
A correct entry for SWAMPID is needed to to let Autobuild connect to this Issue
and do some work automatically.

Please use
        /work/src/bin/edit_patchinfo [-b] <package_1> [ ... <package_n>]
to create the patchinfo. Use the flag -b if it is for SUSE-Linux (Box).

Please use this SWAMP-ID: 2234


--
This Message was automatically generated by the the WebSWAMP-Server at
https://swamp.suse.de/webswamp/swamp

CAN-2005-2495/VU#102441 still could not be found on the www.cert.org website. 

It's in X.Org CVS now: 
 
To: xorg-commit@lists.freedesktop.org 
From: Daniel Stone <xorg-commit@cvs.freedesktop.org> 
Date: Mon, 12 Sep 2005 18:33:19 -0700 (PDT) 
Subject: CVS Update: xc (branch: trunk) 
 
CVSROOT:        /cvs/xorg 
Module name:    xc 
Changes by:     daniels@gabe.freedesktop.org    05/09/12 18:33:19 
 
Log message: 
  * programs/Xserver/afb/afbpixmap.c: 
  * programs/Xserver/cfb/cfbpixmap.c: 
  * programs/Xserver/mfb/mfbpixmap.c: 
  * programs/Xserver/fb/fbpixmap.c: 
  * programs/Xserver/dix/dispatch.c: 
  * programs/Xserver/dix/pixmap.c: 
  * programs/Xserver/hw/xfree86/exa/exapixmap.c: 
  * programs/Xserver/hw/xfree86/xaa/xaaInit.c: 
  * programs/Xserver/hw/xfree86/xf4bpp/ppcPixmap.c: 
  * programs/Xserver/ilbm/ilbmpixmap.c: 
  * programs/Xserver/iplan2p4/iplpixmap.c: 
  Bug #594: CAN-2005-2495: Fix exploitable integer overflow in pixmap 
  creation, where we could create a far smaller pixmap than we thought, 
  allowing changes to arbitrary chunks of memory.  (Søren Sandmann 
  Pedersen) 
 
Modified files: 
      ./: 
        ChangeLog 
      xc/programs/Xserver/afb/: 
        afbpixmap.c 
      xc/programs/Xserver/cfb/: 
        cfbpixmap.c 
      xc/programs/Xserver/dix/: 
        dispatch.c pixmap.c 
      xc/programs/Xserver/fb/: 
        fbpixmap.c 
      xc/programs/Xserver/hw/xfree86/exa/: 
        exa.c 
      xc/programs/Xserver/hw/xfree86/xaa/: 
        xaaInit.c 
      xc/programs/Xserver/hw/xfree86/xf4bpp/: 
        ppcPixmap.c 
      xc/programs/Xserver/ilbm/: 
        ilbmpixmap.c 
      xc/programs/Xserver/iplan2p4/: 
        iplpixmap.c 
      xc/programs/Xserver/mfb/: 
        mfbpixmap.c 
 
  Revision      Changes    Path 
  1.1319        +18 -0     xc/ChangeLog 
  1.6           +6 -2      xc/programs/Xserver/afb/afbpixmap.c 
  1.6           +5 -2      xc/programs/Xserver/cfb/cfbpixmap.c 
  1.13          +17 -0     xc/programs/Xserver/dix/dispatch.c 
  1.8           +3 -0      xc/programs/Xserver/dix/pixmap.c 
  1.6           +4 -2      xc/programs/Xserver/fb/fbpixmap.c 
  1.18          +3 -0      xc/programs/Xserver/hw/xfree86/exa/exa.c 
  1.8           +3 -0      xc/programs/Xserver/hw/xfree86/xaa/xaaInit.c 
  1.4           +5 -1      xc/programs/Xserver/hw/xfree86/xf4bpp/ppcPixmap.c 
  1.5           +4 -2      xc/programs/Xserver/ilbm/ilbmpixmap.c 
  1.5           +4 -2      xc/programs/Xserver/iplan2p4/iplpixmap.c 
  1.5           +4 -2      xc/programs/Xserver/mfb/mfbpixmap.c 
 
_______________________________________________ 
xorg-commit mailing list 
xorg-commit@lists.freedesktop.org 
http://lists.freedesktop.org/mailman/listinfo/xorg-commit 
 

high profile issue. 

It's still not mentioned on the cert website. :-(

X.Org hasn't issued an advisory either.
I've sent in a proposal for an advisory however so far nobody cared.
Also Leon Shiman - the only person who currently has access to the X.Org server
where we place patches and advisories - is busy advising the State of
Massachusetts in open source questions :-/ He should be on the security list also.

patch will be here:  http://www.x.org/pub/X11R6.8.2/patches/xorg-CAN-2005-2495.patch

Nevertheless we should take the patch from their CVS and start our update process.

Created attachment 49778 [details]
Patch from X.Org CVS

Packages and patchinfo files are submitted now:

/work/src/done/9.3/xorg-x11
/work/src/done/9.2/xorg-x11
/work/src/done/9.1/XFree86
/work/src/done/SLES9-SP3/XFree86
/work/src/done/9.0/XFree86
/work/src/done/SLEC/XFree86
/work/src/done/SLES8/xf86

/work/src/done/PATCHINFO/xorg-x11-box.patchinfo
/work/src/done/PATCHINFO/XFree86-box.patchinfo
/work/src/done/PATCHINFO/XFree86.patchinfo
/work/src/done/PATCHINFO/xf86.patchinfo

Thanks a lot.

Resent-Date: 16 Sep 2005 17:02:53 -0000
From: Paul M Anderson <pma@fc.hp.com>
To: Egbert Eich <eich@suse.de>, Leon Shiman <leon@magic.shiman.com>
Cc: Alan.Coopersmith@Sun.COM, eich@suse.de, xorg_security@x.org,
        leon@shiman.com, sandmann@redhat.com, daniel@fooishbar.org
Subject: Re: Advisory and Patch on CAN-2005-2495
Date: Fri, 16 Sep 2005 11:02:43 -0600
Resent-Message-ID: <P_nUfC.A.KME.9qvKDB@mailman>
Resent-To: xorg_security@opengroup.org
Resent-From: xorg_security@opengroup.org
Resent-Sender: xorg_security-request@opengroup.org


Marc La France recently posted some alternate fixes on devel@xfree86.org this
morning.
Has anyone taken a look at those yet?

-paul

SUSE QA:

I'm unable to reproduce this bug on SLES9 with the PS file given at
https://bugs.freedesktop.org/show_bug.cgi?id=594 (link from the initial bug
description).

Can you provide a working bugfix test/exploit ?

Created attachment 50745 [details]
reproduce.c

testcase to reproduce (from fdo bugzilla).

gcc -O2 -o reproduce reproduce.c -L/usr/X11R6/lib -lX11
./reproduce

The program from c#45 does crash Xvnc, too !!!

Also the new Xvnc? 

packages approved.

Will close after comment #47 is answered.

which xvncs did you find affected, heiko? 

/usr/X11R6/bin/Xvnc from XFree86-Xvnc on at least sles9-i386 and sles9-x86_64

iirc I was _not_ able to reproduce this on sles8 (I can't have a look right now
because we move our reference hosts)

The most important question of comment #47 still remains. :-(

I can _not_ reproduce this with SL 10.0 (xorg-x11-Xvnc-6.8.2-100).

New means Xvnc built from new sources. Of course Xvnc from SL 10.0 is not
affected since SL 10.0 already contains the security patch.

Addition to C#52:
SL 9.3 (xorg-x11-Xvnc-6.8.2-30) is affected.

# rpm -qp /work/CDs/all/full-9.3-i386/suse/i586/xorg-x11-Xvnc.rpm 
xorg-x11-Xvnc-6.8.2-30.4

Could you please test the rebuilded packages? Otherwise testing makes no sense.

/work/CDs/all/full-9.3-i386/suse/i586/xorg-x11-Xvnc.rpm 
seems not be affected.

Please note that it is not the job of QA to test rebuilt packages.
This is the maintainer's job!

Ok. Thanks. Then we should add the according packages to the patchinfo files.
Unfortunately these are no longer in /work/src/done/PATCHINFO. :-(

Thomas, should I resubmit them?

the packages have already been released. 
 
For which distros and which packages we need them, then I can just create 
seperate ones. 
 
Do we need more fixed sources or where they fixed by the original checkin 
already? 

We don't need any new sources. We only need to add the according packages for
the Xvnc server to the patchinfo files. I can take care of this. Is this consecutive
to the previous patchinfo files or should I mention the XFree86/X.Org server
package in the patchinfo file again, i.e. option a) or b) :-) ?

a) PACKAGE: xorg-x11-Xvnc
b) PACKAGE: xorg-x11-server xorg-x11-Xvnc

use versiuon (a), no need to rerelease the server packages again. 
 
 

done.

/work/src/done/PATCHINFO/XFree86-box.patchinfo
/work/src/done/PATCHINFO/XFree86.patchinfo
/work/src/done/PATCHINFO/xorg-x11-box.patchinfo

XFree86-Xvnc is *not* on SLEC. On SLES8 the Xvnc server is still in package vnc.
Maintainer is max. I'm sorry, Reinhard!

Oops, I forgot to add Reinhard to Cc. Reinhard, could you read the comment #61?
The patch, which probably needs to be applied, is in comment #40.

Stefan, could you or someone from the security team look into this for me,
please? I am on a part-time parental vacation until end of November and alrady
way ahead with my working hours.

If there's no backup available for you, IMHO your team leader needs to take  
care of this. Adding mmj to Cc. Mads, see comment #62. 

Yes, that's what I'm here for :-)

A lot of the files touched by the patch, isn't present in the vnc sources.

Does /work/users/mmj/vnc look correct to you guys?

Thanks. The patch looks good. The files are simply not used by the vnc  
server. :-)  
  
programs/Xserver/afb/afbpixmap.c  
programs/Xserver/fb/fbpixmap.c  
programs/Xserver/hw/xfree86/xaa/xaaInit.c  
programs/Xserver/hw/xfree86/xf4bpp/ppcPixmap.c  
programs/Xserver/ilbm/ilbmpixmap.c  
programs/Xserver/iplan2p4/iplpixmap.c  
 
Could you submit the package? I'll attach a patchinfo file. 
  

Created attachment 51310 [details]
vnc.patchinfo

http://www.suse.de/~sndirsch/nvidia-installer-HOWTO.html 
http://www.suse.de/~sndirsch/nvidia-installer-HOWTO.html#19 
 
[...] 
Since (open)SuSE Linux 10.0 you need to add the following entries to  
/etc/udev/static_devices.txt:  
  
nvidia c 195 0 666  
nvidia c 195 1 666  
nvidia c 195 2 666  
nvidia c 195 3 666  
nvidia c 195 4 666  
nvidia c 195 5 666  
nvidia c 195 6 666  
nvidia c 195 7 666  
nvidiactl c 195 255 666  
 

Argh. Wrong bug report. :-( 

Thanks for thew patchinfo, package submitted.

Thanks for your help, Mads! 

Thank you both!

approved sles9 packages and box. just wait for vnc of sles8

The update for sles8-x86_64 (vnc-3.3.3r2-574, fa48d73c7f1955c248feb537a6a7cfcb)
is broken. Xvnc crashes upon start:

Oct  6 16:21:48 sol Xvnc[22402]: connect from 10.10.2.8 (10.10.2.8)
Oct  6 16:21:48 sol kernel: Xvnc[22402]: segfault at 0000000095afadf0 rip
0000002a9595ab17 rsp 0000007fbfffeec0 error 4

Downgrading to vnc-3.3.3r2-504 helped getting a working Xvnc again.

> Downgrading to vnc-3.3.3r2-504 helped getting a working Xvnc again.
Is this the x86 or the x86_64 one?

Heiko did use the x86_64 one. AFAIK and according to Reinhard the x86_64 one
never did work. Instead the i586 one needs to be used on x86_64. And this works
fine for me.

all packages approved

CVE-2005-4095: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:P/I:N/A:N)