bug#2370: 23.0.90; decode-coding-region make emacs crash

bug#2370: 23.0.90; decode-coding-region make emacs crash

[Chong Yidong]

Hi Handa-san,

Please take a look at this bug:

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2370

The crash occurs because of memory corruption due to overwriting the
carrover buffer at line 6809 of coding.c.  For the sample provided by
the OP, (coding->src_bytes - coding->consumed) == 99.  This looks like a
bug in decode_coding_iso_2022.

bug#2370: 23.0.90; decode-coding-region make emacs crash

[Kenichi Handa]

In article <87zlgjwa8b.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes:

> Hi Handa-san,
> Please take a look at this bug:

> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2370

> The crash occurs because of memory corruption due to overwriting the
> carrover buffer at line 6809 of coding.c.  For the sample provided by
> the OP, (coding->src_bytes - coding->consumed) == 99.  This looks like a
> bug in decode_coding_iso_2022.

I found two bugs related to this problem, and just installed
a fix for one of them.  Now the above specific problem
should be fixed.  I'll keep on workning to fix the other bug
to make the decoding more robust.

---
Kenichi Handa
handa@m17n.org

bug#2370: 23.0.90; decode-coding-region make emacs crash

[Chong Yidong]

Kenichi Handa <handa@m17n.org> writes:

> I found two bugs related to this problem, and just installed
> a fix for one of them.  Now the above specific problem
> should be fixed.  I'll keep on workning to fix the other bug
> to make the decoding more robust.

Thanks.  I think decode_coding should also verify the size of the
unprocessed bytes before writing them to coding->carrover.  This way,
future bugs of this sort will not cause memory corruption (which might
be a security concern).  What's your opinion?

bug#2370: 23.0.90; decode-coding-region make emacs crash

[Kenichi Handa]

In article <87d4dfqg5h.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes:

> Kenichi Handa <handa@m17n.org> writes:
> > I found two bugs related to this problem, and just installed
> > a fix for one of them.  Now the above specific problem
> > should be fixed.  I'll keep on workning to fix the other bug
> > to make the decoding more robust.

> Thanks.  I think decode_coding should also verify the size of the
> unprocessed bytes before writing them to coding->carrover.  This way,
> future bugs of this sort will not cause memory corruption (which might
> be a security concern).  What's your opinion?

Yes.  I'm going to add such a check.

But it doesn't solve the underlying problem of handling too
long (and wrong) composition sequence in iso-2022 decoding.
Solving it requires a little bit more time.

---
Kenichi Handa
handa@m17n.org

bug#2370: 23.0.90; decode-coding-region make emacs crash

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Date: Thu, 19 Feb 2009 11:46:51 +0900
> Cc: h-fujishima@sakura.ad.jp, 2370@emacsbugs.donarmstrong.com
> 
> I found two bugs related to this problem, and just installed
> a fix for one of them.  Now the above specific problem
> should be fixed.

Thanks.

Please be sure to mention the bug report number in the ChangeLog entry
for the change that fixes the bug.

bug#2370: 23.0.90; decode-coding-region make emacs crash

[Hiroshi Fujishima]

[-- Attachment #1: Type: text/plain, Size: 251 bytes --]

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

gunzip yyy.gz and eval following:

(with-temp-buffer
  (insert-file-contents-literally "~/yyy")
  (decode-coding-region (point-min) (point-max) 'undecided))


[-- Attachment #2: yyy.gz --]
[-- Type: application/octet-stream, Size: 107 bytes --]

[-- Attachment #3: Type: text/plain, Size: 2274 bytes --]


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/local/share/emacs/23.0.90/etc/DEBUG for instructions.

(gdb) bt full
#0  0x28ccba07 in kill () from /lib/libc.so.7
No symbol table info available.
#1  0x0811c7e4 in fatal_error_signal (sig=11) at emacs.c:403
No locals.
#2  <signal handler called>
No symbol table info available.
#3  Fdecode_coding_region (start=Cannot access memory at address 0xbf0a2329
) at coding.c:8639
No locals.
Previous frame inner to this frame (corrupt stack?)
(gdb) xbacktrace
"decode-coding-region" (0xbfbfe070)
"progn" (0xbfbfe134)
"unwind-protect" (0xbfbfe1d4)
"save-current-buffer" (0xbfbfe284)
"with-current-buffer" (0xbfbfe304)
"let" (0xbfbfe3e4)
"with-temp-buffer" (0xbfbfe464)
"eval" (0xbfbfe508)
"eval-last-sexp-1" (0xbfbfe634)
"eval-last-sexp" (0xbfbfe7b4)
"call-interactively" (0xbfbfe974)

In GNU Emacs 23.0.90.1 (i386-unknown-freebsd7.1, GTK+ Version 2.14.7)
 of 2009-02-16 on sea.sakura.ad.jp
Windowing system distributor `Colin Harrison', version 11.0.70400002
configured using `configure  '--without-freetype' '--without-xft''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: ja_JP.eucJP
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: japanese-iso-8bit-unix
  default-enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
  gnus-topic-mode: t
  gnus-undo-mode: t
  auto-insert-mode: t
  iswitchb-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
ESC x r e p o r <tab> <return>

Recent messages:
nnml: Reading incoming mail (3 new)...done
Reading active file via nnml...done
Generating the cache active file...done
No new newsgroups
Checking new news...done