Subject: bug#6855: closed (Re: bug#6855: 24.0.50; Bug in tool bar label handling)

From: [email-masked] (GNU bug Tracking System)
Date: Sun, 15 Aug 2010 08:20:03 +0000

Your bug report

#6855: 24.0.50; Bug in tool bar label handling

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
6855: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6855
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#6855: 24.0.50; Bug in tool bar label handling
From: Jan Djärv <[email-masked]>
To: Johan Bockgård <[email-masked]>
Cc: [email-masked]
Date: Sun, 15 Aug 2010 10:20:05 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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.

Subject: 24.0.50; Bug in tool bar label handling
From: Johan Bockgård <[email-masked]>
To: [email-masked]
Date: Sat, 14 Aug 2010 14:04:25 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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.