Bug#280384: X11 crashing on 2.4.28
Dear listmembers, I can confirm for my U60 that the XFree86-debug server comes up on 2.4.28. So I seem to be consistent with what Admar said and what Ron has been saying. What makes me wonder, though, is why does the binary loader work with 2.4.27 and does not work with 2.4.28. And, moreover, if it is a loader issue it seems more plausible to me that I can observe additional side effects on 2.4.28 not being related to X11 (like very long reaction times on ping / ssh requests, not settling a network connection for quite a while) A propably dumb question: is that binary loader a simple file? would it be possible to get that loader from another version (like Debian Woody), or is it buried deep down in the kernel? Thank you for your inputs, take care Dieter Jurzitza -- HARMAN BECKER AUTOMOTIVE SYSTEMS Dr.-Ing. Dieter Jurzitza Manager Hardware Systems System Development Industriegebiet Ittersbach Becker-Göring Str. 16 D-76307 Karlsbad / Germany Phone: +49 (0)7248 71-1577 Fax: +49 (0)7248 71-1216 eMail: [EMAIL PROTECTED] Internet: http://www.becker.de *** Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. ***
Bug#11147: Economy is finally getting better Thu, 02 Dec 2004 01:30:39 -0800
Today is a new day for your residence. With levels at their headline-making historic lows, our programs are better now than ever before. Even if you've recently closed on a property, now is the time to check your numbers. Our advisors are here to help you decide your options. In fact, did you know that a 30 year fixed program may not always be the best option? There are other ways to do it, and we would like to tell you about it. Find out what all your neighbors are talking about: http://forbestrate.com/?partid=jabby
Bug#283929: xv application lock-ups trident driver
Package: xserver-xfree86 Version: 4.3.0.dfsg.1-8 Hi, I'm running debian testing on Acer travelmate 354TE which has: :01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 5d) videochip installed. The problem is that mplayer with XV video output locks up entire box, kernel doesn't response, network dead, sysrq magic keys also dead. Tried it on debian's 2.4.27 and custom compiled kernel with and without acpi, pci=noacpi in any combination, anyhow it is always reprodusable, but it NEVER lock-up when I start mplayer for the 1st time, sometimes I can start mplayer for the 2nd and 3rd time, but any subsequent mplayers start increase prababilty of system lock. Examining http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/CHANGELOG?rev=HEAD I see various fixes for the trident driver, which of them are incorporated in debian version? Is there newer debian source package of xserver which I try? Thanks in advance! PS: here's device section of XFree86-4 config file: Section Device Identifier Trident Microsystems CyberBlade/i1 Driver trident Option CyberShadow false Option ShadowFB false Option SWcursor false Option PciRetry true Option NoPciBursttrue Option NoAccel false Option UseFB false EndSection
[Virus detected]
Sophos Plc MailMonitor for Domino/D R1.0(4.003c) Server: Domino01 --- Your email contained infected attachment(s). For advice consult your system administrator. --- Mail-Info From: debian-x@lists.debian.org To: [EMAIL PROTECTED] Rec.: [EMAIL PROTECTED] Date: 02-12-2004 12:28:06 Subject:Important --- File: [important.zip] State: [file contains virus]
X Strike Force XFree86 SVN commit: r2039 - in branches/4.1.0/woody/debian: . patches
Author: branden Date: 2004-12-02 08:27:52 -0500 (Thu, 02 Dec 2004) New Revision: 2039 Modified: branches/4.1.0/woody/debian/changelog branches/4.1.0/woody/debian/patches/076_SECURITY_libXpm_vulnerabilities.diff branches/4.1.0/woody/debian/patches/400_hppa_support.diff Log: Apply fixes for CAN-2004-0914 (various Xpm library flaws). * More rigorously declare variables as unsigned integers where appropriate. * Compare user-supplied image data to UINT_MAX, not SIZE_MAX, when the internal corresponding variable used is an unsigned integer. (This is also more correct on LP64 systems.) * Add checks for invalid negative values in user-supplied image data. * Change internal functions WritePixels(), WriteExtensions(), CreatePixels(), and CreateExtensions() to take an additional argument, data_size, to avoid buffer overflows (making the functions less like sprintf and more like snprintf). Update calls to these functions accordingly. * Make macro definitions of compound statements more correct (see Section 3.10.3, Swallowing the Semicolon, of the GNU C Preprocessor Manual). * Add checks for user-supplied data causing integer overflows when summed together. * Add tons of checks for integer overflows generally; even user-data that is legal can become implausible after internal routines manipualte it; return an out-of-memory condition if an overflow is thus caused. * Use snprintf() instead of sprintf() to avoid buffer overflows. * Don't be fooled by XPM images whose image geometry is absurdly huge. * Initialize static buffers with a null byte to prevent string-copying routines from going haywire if the buffers are never populated. * Change some internal functions to return unsigned ints rather than ints. * Add checks for invalid out-of-bounds values in user-supplied data. * Provide private implementation of popen(), intended to be secure, called s_popen(). If the system does not define NO_ZPIPE (only Win32 systems do define it), this is used; otherwise, the system's popen() call is used. Use fclose() instead of pclose() on the file handle thus created. * Use correct data type for size field of a stat structure, instead of casting it to an int. * Use size_t for variables assigned the return value of strlen, not int. * Do not attempt to open image files that have zero-length filenames, or are directories. * Use initializers with static character arrays so that they begin with a null byte if not later reassigned. * Use strncpy() instead of strcpy() to avoid buffer overflows. * Set the final byte of a static character array to null after copying another string into it with strncpy(). * When opening an image file for writing, do not open a file specification that is zero-length, begins or ends with '/', or has '../' anywhere within it. * Use XDestroyImage() and XpmFree() to deallocate resources when bailing out during certain error conditions. * Add many comments suggesting possibilities for further code review and development. Resync offsets in patch #400. Modified: branches/4.1.0/woody/debian/changelog === --- branches/4.1.0/woody/debian/changelog 2004-11-22 11:46:20 UTC (rev 2038) +++ branches/4.1.0/woody/debian/changelog 2004-12-02 13:27:52 UTC (rev 2039) @@ -1,3 +1,12 @@ +xfree86 (4.1.0-16woody5) stable-security; urgency=low + + * Security update release. Resolves the following issue: ++ CAN-2004-0914: memory leak, improper use of signed integers, and + overflow corrections in the Xpm library + * Resync offset in patch #400. + + -- Branden Robinson [EMAIL PROTECTED] Thu, 2 Dec 2004 00:04:22 -0500 + xfree86 (4.1.0-16woody4) stable-security; urgency=high * Security update release. Resolves the following issues: Modified: branches/4.1.0/woody/debian/patches/076_SECURITY_libXpm_vulnerabilities.diff === --- branches/4.1.0/woody/debian/patches/076_SECURITY_libXpm_vulnerabilities.diff 2004-11-22 11:46:20 UTC (rev 2038) +++ branches/4.1.0/woody/debian/patches/076_SECURITY_libXpm_vulnerabilities.diff 2004-12-02 13:27:52 UTC (rev 2039) @@ -1,7 +1,8 @@ $Id$ Fix several security flaws in the Xpm library. Resolves CAN-2004-0687 (libXpm -stack overflows) and CAN-2004-0688 (libXpm integer overflows). +stack overflows), CAN-2004-0688 (libXpm integer overflows), and +CAN-2004-0914 (more integer overflows). The following text is by Chris Evans. @@ -60,12 +61,69 @@ 8192 bytes). The user gets to choose how many bytes to put into this buffer via the number of bytes per pixel XPM value. -This patch by Matthieu Herrb. +The discovery of the above flaws prompted a code review of the Xpm library +by Thomas Biege and several more fixes, including: -diff -urN xc/extras/Xpm~/lib/Attrib.c xc/extras/Xpm/lib/Attrib.c xc/extras/Xpm~/lib/Attrib.c2004-09-18 12:39:38.0
Bug#280384: X11 crashing on 2.4.28
Ok, I think that I've found the problem. The XFree86 binary does its own
object loading and on sparc it is failing to set the PROT_EXEC bit when
mapping executable code. This is falling over a change in the kernel
which checks the executable bit and gives a Segmentation Fault.
Full rationale, explanation and proposed patch below.
Richard
I was looking through the changes between 2.4.27 and 2.4.28 and there is
a patch that adds a check that executed code is actually mapped as
executable (one bit of it is)
diff -urN linux-2.4.27/arch/sparc64/mm/fault.c
linux-2.4.28/arch/sparc64/mm/fault.c
--- linux-2.4.27/arch/sparc64/mm/fault.c2004-08-07
16:26:04.0 -0700
+++ linux-2.4.28/arch/sparc64/mm/fault.c2004-11-17
03:54:21.156379721 -0800
@@ -404,6 +404,16 @@
*/
good_area:
si_code = SEGV_ACCERR;
+
+ /* If we took a ITLB miss on a non-executable page, catch
+* that here.
+*/
+ if ((fault_code FAULT_CODE_ITLB) !(vma-vm_flags
VM_EXEC)) {
+ BUG_ON(address != regs-tpc);
+ BUG_ON(regs-tstate TSTATE_PRIV);
+ goto bad_area;
+ }
+
if (fault_code FAULT_CODE_WRITE) {
if (!(vma-vm_flags VM_WRITE))
goto bad_area;
Now given that this reports a SIGSEGV if you hit this issue (see
SEGV_ACCERR at the top of the patch) I figured that this would be
something that could be triggered.
Now looking at the broken strace from 2.4.28 we see two mmaps during the
loading of module pcidata. These correspond to the text(code) and data
sections of the binary.
mmap(NULL, 163840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x70272000
lseek(5, 229836, SEEK_SET) = 229836
read(5, \0pci_vendor_003d\0pci_vendor_0e11..., 157024) = 157024
brk(0) = 0x274000
brk(0x296000) = 0x296000
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7029a000
lseek(5, 380, SEEK_SET) = 380
read(5, \201\303\340\10\220\20 \1\201\303\340\10\1\0\0\0\235\343...,
1612) = 1612
Note that neither has PROT_EXEC set in the mmap. The second one is the
text section that really needs it.
Now looking at the XFree86 code in
xc/programs/Xserver/hw/xfree86/loader/elfloader.c
This gets memory for the data in one of two ways (chosen at compile
time):
xf86loadermalloc - actually a call to the glibc2 malloc
or
mmap.
The mmap specifies PROT_EXEC but I've disassembled the XFree86 binary
and it seems to use the xf86loadermalloc option.
77514: 90 00 40 08 add %g1, %o0, %o0
77518: 40 05 69 49 call 0x1d1a3c
7751c: d0 24 60 48 st %o0, [ %l1 + 0x48 ]
77520: 84 10 00 08 mov %o0, %g2
77524: 80 a2 20 00 cmp %o0, 0
77528: 02 80 00 77 be 0x77704
Apologies to those who don't read SPARC assembler!
The call at 77518 is a call to malloc (from the symbol table)
001d1a3c DF *UND* 0234 GLIBC_2.0 malloc
I'm guessing that malloc doesn't set PROT_EXEC (people generally don't
want it and it would create a security risk).
Now in the elfloader.c file there is a bit of conditional code for ia64
and OpenBSD that does an mprotect to add PROT_EXEC to the code.
So it looks quite clear to me that we need to do the same for sparc.
i.e. apply the following patch (untested I'm afraid)
--- xc/programs/Xserver/hw/xfree86/loader/elfloader.c.orig
2004-12-02 16:56:31.0 +
+++ xc/programs/Xserver/hw/xfree86/loader/elfloader.c 2004-12-02
16:57:42.0 +
@@ -893,7 +893,7 @@
ErrorF( ELFCreateGOT() Unable to reallocate memory\n
);
return FALSE;
}
-# if defined(linux) defined(__ia64__) || defined(__OpenBSD__)
+# if defined(linux) (defined(__ia64__) || defined(__sparc__)) ||
defined(__OpenBSD__)
{
unsigned long page_size = getpagesize();
unsigned long round;
Anyone fancy compiling a new xserver binary?
On Thu, 2004-12-02 at 06:23, Jurzitza, Dieter wrote:
Dear listmembers,
I can confirm for my U60 that the XFree86-debug server comes up on 2.4.28. So
I seem to be consistent with what Admar said and what Ron has been saying.
What makes me wonder, though, is why does the binary loader work with 2.4.27
and does not work with 2.4.28.
And, moreover, if it is a loader issue it seems more plausible to me that I
can observe additional side effects on 2.4.28 not being related to X11 (like
very long reaction times on ping / ssh requests, not settling a network
connection for quite a while)
A propably dumb question:
is that binary loader a simple file? would it be possible to get that loader
from another version (like Debian Woody), or is it buried deep down in the
kernel?
Thank you for your inputs,
take care
Dieter Jurzitza
--
[EMAIL PROTECTED]
Bug#280384: X11 crashing on 2.4.28
At Thu, 02 Dec 2004 17:02:58 +, Richard Mortimer [EMAIL PROTECTED] wrote: Ok, I think that I've found the problem. The XFree86 binary does its own object loading and on sparc it is failing to set the PROT_EXEC bit when mapping executable code. This is falling over a change in the kernel which checks the executable bit and gives a Segmentation Fault. Full rationale, explanation and proposed patch below. ... Wow. Well done! That's certainly consistent with what I see. Anyone fancy compiling a new xserver binary? I'll set one going before I leave work this afternoon. Should have completed by tomorrow morning. .Ron -- Ron Murray ([EMAIL PROTECTED]) http://www.rjmx.net/~ron GPG Public Key Fingerprint: F2C1 FC47 5EF7 0317 133C D66B 8ADA A3C4 D86C 74DE
Re: ATI Radeon 9200 256MB PCI xfree86-4.3.0.1 - hang
Boris Kolpackov [EMAIL PROTECTED] writes: I am having problems with above-mentioned card. After startx the box just hangs (black screen) with the only way out is through power-down (C-A-Backspace doesn't work). There is no log in /var/log/XFree86.0.log. Here is some info: * Card is VisionTek eXtasy Radeon 9200 256MB PCI DVI/VGA/SV DeviceID is 5961 * XFree86-4.3.0.1 is from Debian unstable. I have disabled DRI (see config below). * I am running linux kernel 2.6.4. I have disabled AGP/Framebuffer. * Driver from ATI v3.14.6 (for 4.3.0) seem to work ok. * I tried various options for radeon driver (you can see them in config file below) without any difference. Meantime I continued poking the radeon driver. Since after the startx the box is totally wasted I decide to ssh from a remote box and run XFree86 -verbose. This way I at least could capture some output. The whole thing appeared to hang right after (--) Depth 24 pixmap format 32 bpp and just before (II) do I need RAC? No, I don't. So I started comparing output from ATI driver to the one from XFree's radeon. All important things seemed identical (like addresses of MMIO regs, V_BIOS segment, BIOS, Linear Framebuffer, etc) except the amount of memory the driver detected. ATI's driver reported 128MB (64bit DDR SDRAM) while radeon reported 256 (128bit DDR SDRAM). So I added VideoRam 131072 to the video card section of XF86Config-4. And everything just worked. Has anybody else experienced anything like this? hth, -boris Section Files FontPathunix/:7110# local font server # if the local font server has problems, we can fall back on these # FontPath /usr/lib/X11/fonts/Type1 # FontPath /usr/lib/X11/fonts/CID # FontPath /usr/lib/X11/fonts/Speedo # FontPath /usr/lib/X11/fonts/misc # FontPath /usr/lib/X11/fonts/cyrillic # FontPath /usr/lib/X11/fonts/100dpi # FontPath /usr/lib/X11/fonts/75dpi EndSection Section Module # LoadGLcore Loadbitmap Loaddbe Loadddc # Loaddri Loadextmod Loadfreetype # Loadglx Loadint10 Loadrecord Loadspeedo Loadtype1 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc104 Option XkbLayout ru Option XkbVariantphonetic Option XkbOptionsgrp:toggle EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/psaux #Option Device/dev/input/mice Option Protocol MouseManPlusPS/2 Option Emulate3Buttons false Option ZAxisMapping 4 5 EndSection Section Device Identifier Generic Video Card #Driver fglrx Driver radeon #ChipID 0x514D #ChipID 0x4966 #BusID PCI:5:14:0 #Option NoAccel true #Option ForcePCIMode true #Option BusType PCI EndSection Section Monitor Identifier Generic Monitor HorizSync 30-75 VertRefresh 50-85 Option DPMS EndSection Section Screen Identifier Default Screen Device Generic Video Card Monitor Generic Monitor DefaultDepth24 SubSection Display Depth 24 Modes 1600x1200 800x600 640x480 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Generic Keyboard InputDevice Configured Mouse EndSection Section DRI Mode0666 EndSection
Bug#284025: xserver-xfree86: SEGV in RADEONQueryConnectedDisplays
Package: xserver-xfree86
Version: 4.3.0.1.dfsg.1-8
Severity: normal
Script started on Thu 02 Dec 2004 04:40:39 PM MST
[EMAIL PROTECTED]:~# gdb /usr/X11R6/bin/XFree86-debug
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as ia64-linux...Using host libthread_db library
/lib/tls/libthread_db.so.1.
(gdb) run
Starting program: /usr/X11R6/bin/XFree86-debug
This is a pre-release version of XFree86, and is not supported in any
way. Bugs may be reported to XFree86@XFree86.Org and patches submitted
to [EMAIL PROTECTED] Before reporting bugs in pre-release versions,
please check the latest version in the XFree86 CVS repository
(http://www.XFree86.Org/cvs).
XFree86 Version 4.3.0.1 (Debian (static) 4.3.0.dfsg.1-8 20040928150828 [EMAIL
PROTECTED])
Release Date: 15 August 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.25-dsa-mckinley-smp ia64 [ELF]
Build Date: 28 September 2004
Before reporting problems, check http://www.XFree86.Org/
to make sure that you have the latest version.
OS Kernel: Linux version 2.6.10-rc2 ([EMAIL PROTECTED]) (gcc version 3.3.3
20040110 (prerelease) (Debian)) #4 SMP Mon Nov 29 16:45:09 MST 2004
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/XFree86.0.log, Time: Thu Dec 2 16:40:56 2004
(==) Using config file: /etc/X11/XF86Config-4
Program received signal SIGSEGV, Segmentation fault.
RADEONQueryConnectedDisplays (pScrn=0x6010a430,
pInt10=0x6010d3c0) at radeon_driver.c:1275
1275radeon_driver.c: No such file or directory.
in radeon_driver.c
(gdb) x/i $pc
0x40834f21 RADEONQueryConnectedDisplays+4161:
ld8 r14=[r14]
(gdb) p $r14
$1 = 568
(gdb) bt
#0 RADEONQueryConnectedDisplays (pScrn=0x6010a430,
pInt10=0x6010d3c0) at radeon_driver.c:1275
#1 0x408368b0 in RADEONGetBIOSParameters (pScrn=0x6010a430,
pInt10=0x6010d3c0) at radeon_driver.c:1456
#2 0x4084dcf0 in RADEONPreInit (pScrn=0x6010a430, flags=0)
at radeon_driver.c:4049
#3 0x40de3780 in InitOutput (pScreenInfo=0x600e93e0, argc=1,
argv=0x6fffb958) at xf86Init.c:574
#4 0x410d2080 in main (argc=1, argv=0x6fffb958,
envp=0x6fffb968) at main.c:361
(gdb) quit
The program is running. Exit anyway? (y or n) y
[EMAIL PROTECTED]:~#
Script done on Thu 02 Dec 2004 04:41:33 PM MST
The problem is pretty clear from the source. We call vbeDoEDID(),
which usually returns a pointer, but can return NULL for failure.
Then we dereference it without bothering to check for NULL:
for (i = 0; i 5; i++) {
pRADEONEnt-MonInfo1 = vbeDoEDID(pVbe, NULL);
}
if (pRADEONEnt-MonInfo1-rawData[0x14] 0x80)
pRADEONEnt-MonType1 = MT_DFP;
else pRADEONEnt-MonType1 = MT_CRT;
Here's a patch:
--- xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c.orig
2004-11-30 13:59:17.314008332 -0700
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 2004-11-30
14:00:14.328656071 -0700
@@ -1272,7 +1272,7 @@
for (i = 0; i 5; i++) {
pRADEONEnt-MonInfo1 = vbeDoEDID(pVbe, NULL);
}
- if (pRADEONEnt-MonInfo1-rawData[0x14] 0x80)
+ if (pRADEONEnt-MonInfo1
pRADEONEnt-MonInfo1-rawData[0x14] 0x80)
pRADEONEnt-MonType1 = MT_DFP;
else pRADEONEnt-MonType1 = MT_CRT;
}
Bug#280384: X11 crashing on 2.4.28
At Thu, 02 Dec 2004 22:41:46 +, Richard Mortimer [EMAIL PROTECTED] wrote: On Thu, 2004-12-02 at 19:27, Ron Murray wrote: At Thu, 02 Dec 2004 13:45:59 -0500, Ron Murray wrote: We have a minor problem. Richard's patch seems to refer to a pristine xfree86-4.3.0 source. Damn! There are two similar #if defined lines. I made the patch against the wrong one! I also accept that I did make the patch against pristine sources - although in this case it means that you spotted my mistake. I still stand by my analysis. Hopefully the new patch (below) will work. Note I've taken the same approach as the one that my original patch clashed with. Basically I've removed the check for ia64 because I'm assuming that the non-executable issue could in future apply to all linux versions. Richard Yep, I agree that you've probably found the problem. After I wrote my previous post, I did some poking around with gdb on the XFree86 executable. I found a sequence of bytes that looked a lot like the ones you posted earlier, a little further on than you had (but my current copy of XFree86 has lots of debugging code inbuilt). They even had a call to malloc() in the middle of them. gdb claimed that the code was in the middle of ELFLoadModule(), so I looked, and there it was, complete with the same #ifdef you found earlier. I set up the patch, started the build, and went home. With any luck, I'll have a new (and hopefully functional) set of X packages when I get to work in the morning. Only difference was that I didn't turn it on for all Linux, just for ia86 and sparc. Wasn't sure whether it was a good idea or not. I'll let everyone know how it went. Thanks for finding it. .Ron -- Ron Murray ([EMAIL PROTECTED]) http://www.rjmx.net/~ron GPG Public Key Fingerprint: F2C1 FC47 5EF7 0317 133C D66B 8ADA A3C4 D86C 74DE
X Strike Force XFree86 SVN commit: r2040 - trunk/debian
Author: branden Date: 2004-12-02 21:33:10 -0500 (Thu, 02 Dec 2004) New Revision: 2040 Modified: trunk/debian/TODO Log: Defer item to -10 per discussion with Fabio. Modified: trunk/debian/TODO === --- trunk/debian/TODO 2004-12-02 13:27:52 UTC (rev 2039) +++ trunk/debian/TODO 2004-12-03 02:33:10 UTC (rev 2040) @@ -17,6 +17,14 @@ 4.3.0.dfsg.1-9 -- +* Add Debian-specific patch to uxterm to call validlocale(8) before trying to + launch xterm, per recommendation from Recai Oktas. If a valid locale isn't + set, bail out (would resolve #246398). (This patch would be Debian-specific + because validlocale is a Perl utility provided by base-config.) + +4.3.0.dfsg.1-10 +-- + * Rewrite xserver-xfree86 debconfage. Joey Hess, Eduard Bloch, and David Nusinow have provided good input. + udev users will have /dev/input/mousen -- configure that as only mouse @@ -48,14 +56,6 @@ users to use 'gb' [BR] + Use /proc/hardware on m68k architecture to set a reasonable default mouse port. See URL: http://lists.debian.org/debian-68k/2004/08/msg00392.html. -* Add Debian-specific patch to uxterm to call validlocale(8) before trying to - launch xterm, per recommendation from Recai Oktas. If a valid locale isn't - set, bail out (would resolve #246398). (This patch would be Debian-specific - because validlocale is a Perl utility provided by base-config.) - -4.3.0.dfsg.1-10 --- - * #245541: Evaluate Sven Luther's driver DDK package patch: http://lists.debian.org/debian-x/2003/debian-x-200311/msg2.html * #253480: xdm: XDM fails if the user is over disk quota, but empty files can
X Strike Force XFree86 SVN commit: r2041 - trunk/debian
Author: branden Date: 2004-12-02 21:39:58 -0500 (Thu, 02 Dec 2004) New Revision: 2041 Modified: trunk/debian/TODO Log: Redefine goals for -9 release. (Fabio is ill, so I will probably be handling this release.) Modified: trunk/debian/TODO === --- trunk/debian/TODO 2004-12-03 02:33:10 UTC (rev 2040) +++ trunk/debian/TODO 2004-12-03 02:39:58 UTC (rev 2041) @@ -17,10 +17,12 @@ 4.3.0.dfsg.1-9 -- -* Add Debian-specific patch to uxterm to call validlocale(8) before trying to - launch xterm, per recommendation from Recai Oktas. If a valid locale isn't - set, bail out (would resolve #246398). (This patch would be Debian-specific - because validlocale is a Perl utility provided by base-config.) +* Apply patch from Richard Mortimer to fix the XFree86 X server's ELF object + loader to set the PROT_EXEC flag on mmap()ed modules regardless of machine + architecture. (It was already trying to do this, but there are two + preprocessor statements involved, and we were only patching one.) + See #280384. +* Rev XTerm to patch #197, which fixes #246398 and several other bugs. 4.3.0.dfsg.1-10 --
X Strike Force XFree86 SVN commit: r2042 - in trunk/debian: . patches
Author: branden Date: 2004-12-02 21:46:41 -0500 (Thu, 02 Dec 2004) New Revision: 2042 Modified: trunk/debian/CHANGESETS trunk/debian/changelog trunk/debian/patches/087_SECURITY_libXpm_vulnerabilities.diff Log: Update patch annotation to describe fixes to CAN-2004-0914. Add changelog entry for CAN-2004-0914 security fix, and increment upload urgency to high. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-12-03 02:39:58 UTC (rev 2041) +++ trunk/debian/CHANGESETS 2004-12-03 02:46:41 UTC (rev 2042) @@ -317,7 +317,7 @@ Update debian/patches/087_SECURITY_libXpm_vulnerabilities.diff to include the latest security fixes and rediff 200_alpha_xpm_get_long64.diff. -2035 +2035, 2042 Sync debian/rules install-server target with install and make binary-server target work again. Modified: trunk/debian/changelog === --- trunk/debian/changelog 2004-12-03 02:39:58 UTC (rev 2041) +++ trunk/debian/changelog 2004-12-03 02:46:41 UTC (rev 2042) @@ -1,5 +1,8 @@ -xfree86 (4.3.0.dfsg.1-8+SVN) unstable; urgency=low +xfree86 (4.3.0.dfsg.1-8+SVN) unstable; urgency=high + * Security update release. Resolves CAN-2004-0914 (several Xpm library +vulnerabilities). + Changes by Branden Robinson: * Update Danish debconf template translations (thanks, Claus Hindsgaul). @@ -274,8 +277,14 @@ * Sync debian/rules install-server target with install and make binary-server work again. - -- Branden Robinson [EMAIL PROTECTED] Wed, 17 Nov 2004 18:00:21 -0500 + Changes by Fabio M. Di Nitto and Branden Robinson: + * Update patch #087 to include fruits of Xpm source code security audit by +Thomas Beige. Resolves CAN-2004-0914: memory leak, improper use of signed +integers, and overflows in the Xpm library. Resync offset in patch #200. + + -- Branden Robinson [EMAIL PROTECTED] Thu, 2 Dec 2004 21:43:03 -0500 + xfree86 (4.3.0.dfsg.1-8) unstable; urgency=high Changes by Denis Barbier: Modified: trunk/debian/patches/087_SECURITY_libXpm_vulnerabilities.diff === --- trunk/debian/patches/087_SECURITY_libXpm_vulnerabilities.diff 2004-12-03 02:39:58 UTC (rev 2041) +++ trunk/debian/patches/087_SECURITY_libXpm_vulnerabilities.diff 2004-12-03 02:46:41 UTC (rev 2042) @@ -1,7 +1,8 @@ $Id$ Fix several security flaws in the Xpm library. Resolves CAN-2004-0687 (libXpm -stack overflows) and CAN-2004-0688 (libXpm integer overflows). +stack overflows), CAN-2004-0688 (libXpm integer overflows), and +CAN-2004-0914 (more integer overflows). The following text is by Chris Evans. @@ -60,8 +61,60 @@ 8192 bytes). The user gets to choose how many bytes to put into this buffer via the number of bytes per pixel XPM value. -This patch by Matthieu Herrb. +The discovery of the above flaws prompted a code review of the Xpm library +by Thomas Biege and several more fixes, including: +* More rigorously declare variables as unsigned integers where appropriate. +* Compare user-supplied image data to UINT_MAX, not SIZE_MAX, when the + internal corresponding variable used is an unsigned integer. (This is + also more correct on LP64 systems.) +* Add checks for invalid negative values in user-supplied image data. +* Change internal functions WritePixels(), WriteExtensions(), + CreatePixels(), and CreateExtensions() to take an additional argument, + data_size, to avoid buffer overflows (making the functions less like + sprintf and more like snprintf). Update calls to these functions + accordingly. +* Make macro definitions of compound statements more correct (see Section + 3.10.3, Swallowing the Semicolon, of the GNU C Preprocessor Manual). +* Add checks for user-supplied data causing integer overflows when summed + together. +* Add tons of checks for integer overflows generally; even user-data that + is legal can become implausible after internal routines manipualte it; + return an out-of-memory condition if an overflow is thus caused. +* Use snprintf() instead of sprintf() to avoid buffer overflows. +* Don't be fooled by XPM images whose image geometry is absurdly huge. +* Initialize static buffers with a null byte to prevent string-copying + routines from going haywire if the buffers are never populated. +* Change some internal functions to return unsigned ints rather than ints. +* Add checks for invalid out-of-bounds values in user-supplied data. +* Provide private implementation of popen(), intended to be secure, called + s_popen(). If the system does not define NO_ZPIPE (only Win32 systems + do define it), this is used; otherwise, the system's popen() call is + used. Use fclose() instead of pclose() on the file handle thus created. +* Use correct data type for size field of a stat structure, instead of + casting it to an int.
Processed: retitle 280384 to xserver-xfree86: [elfloader] SEGV on sparc with Linux 2.6 due to non-PROT-EXEC-ed use of mmap() ...
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.8.5 retitle 280384 xserver-xfree86: [elfloader] SEGV on sparc with Linux 2.6 due to non-PROT-EXEC-ed use of mmap() Bug#280384: xserver-xfree86: X crashes on load, UltraSPARC with 2.6.xx kernel and udev Changed Bug title. tags 280384 + upstream patch Bug#280384: xserver-xfree86: [elfloader] SEGV on sparc with Linux 2.6 due to non-PROT-EXEC-ed use of mmap() There were no tags set. Tags added: upstream, patch End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
X Strike Force XFree86 SVN commit: r2043 - in trunk/debian: . patches
Author: branden
Date: 2004-12-02 23:24:44 -0500 (Thu, 02 Dec 2004)
New Revision: 2043
Modified:
trunk/debian/CHANGESETS
trunk/debian/TODO
trunk/debian/changelog
trunk/debian/patches/071_nonexecutable_malloced_mem.diff
trunk/debian/patches/600_amd64_support.diff
Log:
Apply patch from Richard Mortimer to fix the XFree86 X server's ELF object
loader to set the PROT_EXEC flag on mmap()ed modules regardless of machine
architecture. (It was already trying to do this, but there are two
preprocessor statements involved, and we were only patching one.)
(Closes: #280384)
Modified: trunk/debian/CHANGESETS
===
--- trunk/debian/CHANGESETS 2004-12-03 02:46:41 UTC (rev 2042)
+++ trunk/debian/CHANGESETS 2004-12-03 04:24:44 UTC (rev 2043)
@@ -323,4 +323,11 @@
target work again.
2036
+Apply patch from Richard Mortimer to fix the XFree86 X server's ELF object
+loader to set the PROT_EXEC flag on mmap()ed modules regardless of machine
+architecture. (It was already trying to do this, but there are two
+preprocessor statements involved, and we were only patching one.)
+(Closes: #280384)
+2043
+
vim:set ai et sts=4 sw=4 tw=80:
Modified: trunk/debian/TODO
===
--- trunk/debian/TODO 2004-12-03 02:46:41 UTC (rev 2042)
+++ trunk/debian/TODO 2004-12-03 04:24:44 UTC (rev 2043)
@@ -17,11 +17,6 @@
4.3.0.dfsg.1-9
--
-* Apply patch from Richard Mortimer to fix the XFree86 X server's ELF object
- loader to set the PROT_EXEC flag on mmap()ed modules regardless of machine
- architecture. (It was already trying to do this, but there are two
- preprocessor statements involved, and we were only patching one.)
- See #280384.
* Rev XTerm to patch #197, which fixes #246398 and several other bugs.
4.3.0.dfsg.1-10
Modified: trunk/debian/changelog
===
--- trunk/debian/changelog 2004-12-03 02:46:41 UTC (rev 2042)
+++ trunk/debian/changelog 2004-12-03 04:24:44 UTC (rev 2043)
@@ -192,6 +192,12 @@
one that works on systems that do not have a PCI bus numbered 0. Thanks,
David! (Closes: #279436)
+ * Apply patch from Richard Mortimer to fix the XFree86 X server's ELF object
+loader to set the PROT_EXEC flag on mmap()ed modules regardless of machine
+architecture. (It was already trying to do this, but there are two
+preprocessor statements involved, and we were only patching one.)
+(Closes: #280384)
+
Changes by Denis Barbier and Fabio M. Di Nitto:
* Edit xc/programs/xkbcomp/symbols/pc/Imakefile so that the new pc/us_intl
@@ -283,7 +289,7 @@
Thomas Beige. Resolves CAN-2004-0914: memory leak, improper use of signed
integers, and overflows in the Xpm library. Resync offset in patch #200.
- -- Branden Robinson [EMAIL PROTECTED] Thu, 2 Dec 2004 21:43:03 -0500
+ -- Branden Robinson [EMAIL PROTECTED] Thu, 2 Dec 2004 23:23:30 -0500
xfree86 (4.3.0.dfsg.1-8) unstable; urgency=high
Modified: trunk/debian/patches/071_nonexecutable_malloced_mem.diff
===
--- trunk/debian/patches/071_nonexecutable_malloced_mem.diff2004-12-03
02:46:41 UTC (rev 2042)
+++ trunk/debian/patches/071_nonexecutable_malloced_mem.diff2004-12-03
04:24:44 UTC (rev 2043)
@@ -5,11 +5,13 @@
We understand it is Linus' position that programs that assume data to be
executable are broken, so we enable this code for all Linux platforms.
-Original patch (before upstream applied its own version) was by David
Mosberger.
+An earlier version of this patch only corrected the first #if. Thanks to
+Ron Murray, Admar Schoonen, Jurij Smakov, Dieter Jurzitza, and Richard
+Mortimer for their analysis which helped uncover the other two instances.
-diff -urN xc/programs/Xserver/hw/xfree86/loader/elfloader.c
xc.new/programs/Xserver/hw/xfree86/loader/elfloader.c
xc/programs/Xserver/hw/xfree86/loader/elfloader.c 2004-02-07
17:33:29.0 -0500
-+++ xc.new/programs/Xserver/hw/xfree86/loader/elfloader.c 2004-02-07
17:29:03.0 -0500
+diff -u xc/programs/Xserver/hw/xfree86/loader/elfloader.c~
xc.new/programs/Xserver/hw/xfree86/loader/elfloader.c
+--- xc/programs/Xserver/hw/xfree86/loader/elfloader.c~ 2004-12-02
21:54:11.0 -0500
xc/programs/Xserver/hw/xfree86/loader/elfloader.c 2004-12-02
22:01:41.0 -0500
@@ -957,7 +957,7 @@
ErrorF( ELFCreateGOT() Unable to reallocate memory\n );
return FALSE;
@@ -19,3 +21,21 @@
{
unsigned long page_size = getpagesize();
unsigned long round;
+@@ -2728,7 +2728,7 @@
+ elffile-lsection[j].size=SecSize(i);
+ elffile-lsection[j].flags=flags;
+ switch (SecType(i)) {
+-#ifdef __OpenBSD__
++#if defined(linux) || defined(__OpenBSD__)
+ case SHT_PROGBITS:
+
Processed: tagging 280384
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.8.5 # fixed in Debian X Strike Force XFree86 repository; to view, run svn diff -r 2042:2043 svn://necrotic.deadbeast.net/xfree86 tags 280384 + pending Bug#280384: xserver-xfree86: [elfloader] SEGV on sparc with Linux 2.6 due to non-PROT-EXEC-ed use of mmap() Tags were: patch upstream Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
