Bug 132459

Please read: http://www.opensuse.org/Submit_a_bug
We cannot handle bug reports like those, because they contain no information at all. Reopen it if you can provide the necessary information.

I can reproduce it with 10.1 beta8 on i386 and x86_86 at least:

*** buffer overflow detected ***: grip terminated
======= Backtrace: =========
/lib/libc.so.6(__chk_fail+0x41)[0xf6d30b51]
/lib/libc.so.6[0xf6d30328]
/lib/libc.so.6(_IO_default_xsputn+0xa0)[0xf6cc31c0]
/lib/libc.so.6(_IO_vfprintf+0x374c)[0xf6c9f55c]
/lib/libc.so.6(__vsprintf_chk+0xad)[0xf6d303dd]
/lib/libc.so.6(__sprintf_chk+0x30)[0xf6d30310]
grip[0x805298e]
grip(GripNew+0x2c87)[0x80558a7]
grip(Cmain+0x1fe)[0x804f49e]
grip(main+0x22)[0x804f292]
/lib/libc.so.6(__libc_start_main+0xdc)[0xf6c7687c]
grip(__gxx_personality_v0+0x181)[0x804f1e1]

Of course I should read http://www.opensuse.org/Submit_a_bug too, especially
the section on the importance of how to reproduce, but it should be only a
minor nitpick in the case.

How to reproduce:

Call grip with this command:

LANG=ja_JP.UTF-8 grip

Using .UTF-8 or not does not play a role.

In case you have man LC_* variables set, especifally if you have LC_ALL
set, you may have to use LC_ALL above instead of LANG. It seems to be be
LC_ALL/LANG which triggers the error.

Possibly, when calling grip with valgrind and telling valgrind to start
a debugger on a error like a buffer overflow may point the debugger to
the exact place (possibly the exact string) which causes the buffer overflow.

The other locales which I tested do not seem to be affected.

A very bad workaround would be to remove the ja locale altogether:

rm /opt/gnome/share/locale/ja/LC_MESSAGES/grip-2.2.mo

This would mean that grip would start but be english and not in japanese.

Looking at the stack trace, I see
(on x86_64, where I debugged, so the address is different from above):

...
/lib64/libc.so.6(__sprintf_chk+0x80)[0x2ac7b13584f0]
grip[0x40c79f]
grip(GripNew+0x26b7)[0x40f047]
...

The interesting place, where we could assume to have the direct cause
of the buffer overflow is the line in the middle:

grip[0x40c79f]

Since this does not show us the exact function (we only see it's been
directly called by GripNew, we need to look at the disassembly of the
machine code addess 40c79f of the grip exectuable:

objdump -d /opt/gnome/bin/grip

prints it to stdout.

looking for the address we see:

  40c75d:       e8 2e bc ff ff          callq  408390 <gtk_widget_show@plt>
  40c762:       31 f6                   xor    %esi,%esi
  40c764:       bf 01 00 00 00          mov    $0x1,%edi
  40c769:       e8 72 ce ff ff          callq  4095e0 <gtk_vbox_new@plt>
  40c76e:       31 ff                   xor    %edi,%edi
  40c770:       ba 05 00 00 00          mov    $0x5,%edx
  40c775:       be d5 36 42 00          mov    $0x4236d5,%esi
  40c77a:       49 89 c7                mov    %rax,%r15
  40c77d:       e8 4e c8 ff ff          callq  408fd0 <dcgettext@plt>
  40c782:       41 b8 f0 33 42 00       mov    $0x4233f0,%r8d
  40c788:       48 89 c1                mov    %rax,%rcx
  40c78b:       ba 14 00 00 00          mov    $0x14,%edx
  40c790:       be 01 00 00 00          mov    $0x1,%esi
  40c795:       48 89 df                mov    %rbx,%rdi
  40c798:       31 c0                   xor    %eax,%eax
  40c79a:       e8 71 cd ff ff          callq  409510 <__sprintf_chk@plt>
= 40c79f:       48 89 df                mov    %rbx,%rdi
  40c7a2:       e8 49 c1 ff ff          callq  4088f0 <gtk_label_new@plt>

I added a "=" at the start of the line to show the stack address where
the function which has been called from there would return, so the function
which has been called is shown one line above., it's __sprintf_chk, a version
of sprintf with a buffer overflow check. So it's triggered by a call to sprintf.

I rebuilt the grip rpm on my machine and this created a binary where I was
able to saw that function which contains the sprintf is MakeAboutPage().

It was rather easy from there:

void MakeAboutPage(GripGUI *uinfo)
...
  char versionbuf[20];

  sprintf(versionbuf,_("Version %s"),VERSION);

Since it was the only sprintf call from function (in disassembly and source,
AFAICS) this must be the place. Checking the po file with the japanese
tranlation confirms that there is a buffer overflow there with the ja.po:

po/ja.po
#: src/grip.c:565
#, c-format
msgid "Version %s"
msgstr "バージョン %s"

This msgstr, encodedin in UTF-8 needs 19 bytes, and this includes the %s,
but the %s is not expanded to the version string which is 3.2.0 in this
version, so the result is a buffer overflow by 3 bytes.

I tested that increasting the size of version_buf fixes the problem
and will submit a fix for 10.1-RC1.

Submitted for 10.1-RC1 (hopefully in time).

The changelog entry to identify the fix would be:

* Tue Mar 21 2006 - bk@suse.de
- fix buffer overflow at startup in japanese environment (#132459)

Will set to fixed when I know in which code snapshot/release it will appear.

fix is in the current build, and will be in 10.1

Severity was actually Major, because a crash which happens at every startup
prevents the use of the program and is thus a major loss of functionality,
which constitutes a severity of major.