GNU bug report logs - #6855
24.0.50; Bug in tool bar label handling

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#6855: closed (24.0.50; Bug in tool bar label handling)
Date: Sun, 15 Aug 2010 08:20:03 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sun, 15 Aug 2010 10:20:05 +0200
with message-id <4C67A335.1050002 <at> swipnet.se>
and subject line Re: bug#6855: 24.0.50; Bug in tool bar label handling
has caused the GNU bug report #6855,
regarding 24.0.50; Bug in tool bar label handling
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
6855: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6855
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Johan Bockgård <bojohan <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; Bug in tool bar label handling
Date: Sat, 14 Aug 2010 14:04:25 +0200

There are some bugs in the handling of tool bar labels that can cause
Emacs to crash.



### gtkutil.c: update_frame_tool_bar ###

    char *label = SSDATA (PROP (TOOL_BAR_ITEM_LABEL));

Here we take string data out.



### keyboard.c: parse_tool_bar_item ###

      else if (EQ (key, QClabel))
        {
          /* `:label LABEL-STRING'.  */
          PROP (TOOL_BAR_ITEM_LABEL) = value;
          have_label = 1;
        }

But here we put an arbitrary object in.


...

  if (!have_label)

...
      char buf[64];
      EMACS_INT max_lbl = 2*tool_bar_max_label_size;
      Lisp_Object new_lbl;

      if (strlen (caption) < max_lbl && caption[0] != '\0')
        {
          strcpy (buf, caption);

tool-bar-max-label-size is a user variable, so this can mean a buffer
overflow.


...
      if (SCHARS (new_lbl) <= tool_bar_max_label_size)
        PROP (TOOL_BAR_ITEM_LABEL) = new_lbl;

If we came here but the branch is not taken, the label will be nil,
not a string.

[Message part 3 (message/rfc822, inline)]

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Johan Bockgård <bojohan <at> gnu.org>
Cc: 6855-done <at> debbugs.gnu.org
Subject: Re: bug#6855: 24.0.50; Bug in tool bar label handling
Date: Sun, 15 Aug 2010 10:20:05 +0200

Johan Bockgård skrev 2010-08-14 14.04:
>
> There are some bugs in the handling of tool bar labels that can cause
> Emacs to crash.
>
>
>
> ### gtkutil.c: update_frame_tool_bar ###
>
>      char *label = SSDATA (PROP (TOOL_BAR_ITEM_LABEL));
>
> Here we take string data out.
>
>
>
> ### keyboard.c: parse_tool_bar_item ###
>
>        else if (EQ (key, QClabel))
>          {
>            /* `:label LABEL-STRING'.  */
>            PROP (TOOL_BAR_ITEM_LABEL) = value;
>            have_label = 1;
>          }
>
> But here we put an arbitrary object in.
>

We kind of assume people do the sensible thing and put in strings.  It is the
same as for help and image.  If Emacs crashes because somebody didn't put
in a string, that is actually a good thing IMHO.  The error becomes very
apparent then.

>
> ...
>
>    if (!have_label)
>
> ...
>        char buf[64];
>        EMACS_INT max_lbl = 2*tool_bar_max_label_size;
>        Lisp_Object new_lbl;
>
>        if (strlen (caption)<  max_lbl&&  caption[0] != '\0')
>          {
>            strcpy (buf, caption);
>
> tool-bar-max-label-size is a user variable, so this can mean a buffer
> overflow.
>
>
> ...
>        if (SCHARS (new_lbl)<= tool_bar_max_label_size)
>          PROP (TOOL_BAR_ITEM_LABEL) = new_lbl;
>
> If we came here but the branch is not taken, the label will be nil,
> not a string.
>

I have checked in a fix for those two.

Thanks,

	Jan D.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.