Created attachment 322919 [details] Fix Memory fault when X11 server provides oddball fonts. Description of problem: Memory fault. Version-Release number of selected component (if applicable): tk-8.4.7 (in Fedora 8, tk-8.4.17) How reproducible: Consistently Steps to Reproduce: 1.Have an X server with these fonts available: sschaefe@modelb00h xlsfonts | fgrep 'misc-????' -misc-????-bold-r-normal--0-0-0-0-p-0-iso8859-1 -misc-????-bold-r-normal--0-0-0-0-p-0-microsoft-symbol -misc-????-medium-r-normal--0-0-0-0-p-0-iso8859-1 -misc-????-medium-r-normal--0-0-0-0-p-0-microsoft-symbol 2.Attempt to display oddball Unicode characters using the Tk library, for instance, run the following python program: sschaefe@modelb00h cat t2.py # -*- coding: utf-8 -*- import sys, Tkinter, unicodedata u = u'(a\u00c9\u03a9B\u3045\u4e7cz):\n' # '(aÉΩBぅ乼cz):\n' Tkinter.Button(text=u, command=sys.exit).pack( ) Tkinter.mainloop( ) 3. python t2.py Actual results: Memory fault Expected results: Display button containing Unicode characters. Additional info: The attached patch solves the problem for me.
I can't reproduce this. Please what is the source of problematic fonts? I did: # yum install '*font*' # xlsfonts | fgrep 'misc-????' | wc -l 0 I think in properly configured X there shouldn't be any '?' in font names.
The fonts in question are the result of following the instructions at http://www.mozilla.org/projects/mathml/fonts/ for support of MathML under Firefox 2; specifically, download http://support.wolfram.com/technotes/fonts/windows/files/MathFonts_TrueType_41.exe; then mkdir $font_dir cd $font_dir unzip $download_dir/MathFonts_TrueType_41.exe mkfontscale mkfontdir; xset +fp `pwd` xset fp rehash This is an failure in the *client* to check the failure result of function calls; see the patch. There are conventions concerning font names, but the only hard restriction is that they are null terminated strings. Tk is dereferencing a NULL pointer; it's much easier to fix that than determine whether it constitutes a security vulnerability.
Created attachment 403460 [details] tk-8.4.7-sigsegv.patch According to "X Logical Font Description Conventions": Field values are constructed as strings of ISO 8859-1 graphic characters, excluding the following: − (HYPHEN), the XLFD font name delimiter character ? (QUESTION MARK) and * (ASTERISK), the X protocol font name wildcard characters , (COMMA), used by Xlib to separate XLFD font names in a font set. " (QUOTATION MARK), used by some commercial products to quote a font name. Thus the result of mkfontscale seems not to be valid here. I will file bug on it. I agree that the client shouldn't hang even under these circumstances, but your patch seems for mee too restrictive and far from the call causing the hang. I propose less restrictive solution (in attachement). It seems there are no more calls that could hang, but maybe I overlooked something, so any comments are welcome.
The mkfontscale issue continues in Bug 578460.
The prerequisite for this bug is misconfiguration of X. The included patch fixes SIGSEGV under this condition. But other tools also SIGSEGV under this condition (e.g. xfontsel). Probably better solution than fixing all of these tools would be back-porting mkfontscale fix from the Bug 578460 that prevents misconfiguration of X from happening.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Red Hat does not currently plan to fix this issue in a Red Hat Enterprise Linux update for currently deployed products. With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating enhancements and defects for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects. For more information on Red Hat Enterprise Linux maintenance policies, please consult: http://www.redhat.com/security/updates/errata/