Bug#454212: megahal segfaults as soon as it's launched

2008-02-13 Thread Niko Tyni
On Mon, Feb 11, 2008 at 10:18:37AM +, Neil McGovern wrote:
 Niko Tyni wrote:
 Confirmed using etch i386 (though an amd64 processor). Attached output
 of megahal and strace.
 
 The attached patch fixes a stack corruption issue on 64-bit architectures
 (reading 8 bytes into a 4-byte buffer) and an off-by-one sprintf overflow
 in the error and status file name initialization code.

 Confirmed that this patch fixes the issue, at least on the version in Etch.
 
 This issue probably qualifies for a stable point update (-release in 
 cc). I can prepare a package if you want.

Just a clarification: I'm not the megahal maintainer, and in fact Laurent
Fousse recently orphaned it. I'm only interested in megahal because of
#463146, related to the future Perl 5.10 transition.

Cc'ing Laurent, as he still seems somewhat interested and was probably
out of the loop wrt. the patch.

No opinion on the stable update, but I suppose I could prepare a QA
upload to sid myself if nobody steps up and adopts this...

Cheers,
-- 
Niko Tyni   [EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#454212: megahal segfaults as soon as it's launched

2008-02-13 Thread Laurent Fousse
Hello,

* Niko Tyni [Wed, Feb 13, 2008 at 11:08:12AM +0200]:
 On Mon, Feb 11, 2008 at 10:18:37AM +, Neil McGovern wrote:
  Niko Tyni wrote:
  Confirmed using etch i386 (though an amd64 processor). Attached output
  of megahal and strace.
  
  The attached patch fixes a stack corruption issue on 64-bit architectures
  (reading 8 bytes into a 4-byte buffer) and an off-by-one sprintf overflow
  in the error and status file name initialization code.
 
  Confirmed that this patch fixes the issue, at least on the version in Etch.
  
  This issue probably qualifies for a stable point update (-release in 
  cc). I can prepare a package if you want.
 
 Just a clarification: I'm not the megahal maintainer, and in fact Laurent
 Fousse recently orphaned it. I'm only interested in megahal because of
 #463146, related to the future Perl 5.10 transition.
 Cc'ing Laurent, as he still seems somewhat interested and was probably
 out of the loop wrt. the patch.

Yup, I missed the mail. Thanks Niko for Cc'ing me. And for the patch,
of course.

 No opinion on the stable update, but I suppose I could prepare a QA
 upload to sid myself if nobody steps up and adopts this...

I don't have my GPG key at work, so it will have to wait for this
evening. If you have a package ready go ahead.

The reason I orphaned megahal is because I read its code too much for
my own good recently. If it weren't for users I'd suggest removal :-)

Over the time megahal has acquired a number of extension I seldom, if
ever, used. It would be best if megahal was team-maintained by people
who actually care about a Tcl, Python, and Perl module (and are
willing to cope with the C codebase too).

I've more or less given up. Markovian models are not hard to code
properly, and I've just done that for a spam filter I consider
including in debian. Writing a megahal replacement from that is just a
matter of providing python bindings.

Regards,

Laurent.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#454212: megahal segfaults as soon as it's launched

2008-02-13 Thread Niko Tyni
tag 454212 - unreproducible
tag 454212 + patch
thanks

On Sun, Feb 10, 2008 at 09:21:01PM +0200, Niko Tyni wrote:
 
 However, the original problem is on i386 and happens earlier in the
 initialization code. I can't reproduce it myself, but I think it might
 well be caused by the sprintf overflow.

Heh, one more thing: I was able to reproduce this on i386 with a username
of nine characters. Verified that the patch really fixes this; the
sprintf() overflow apparently corrupts a memory area allocated by fopen().

Cheers,
-- 
Niko Tyni   [EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Processed: Re: Bug#454212: megahal segfaults as soon as it's launched

2008-02-13 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

 tag 454212 - unreproducible
Bug#454212: megahal segfaults as soon as it's launched
Tags were: unreproducible
Tags removed: unreproducible

 tag 454212 + patch
Bug#454212: megahal segfaults as soon as it's launched
There were no tags set.
Tags added: patch

 thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#454212: megahal segfaults as soon as it's launched

2008-02-11 Thread Neil McGovern

Niko Tyni wrote:

Confirmed using etch i386 (though an amd64 processor). Attached output
of megahal and strace.


The attached patch fixes a stack corruption issue on 64-bit architectures
(reading 8 bytes into a 4-byte buffer) and an off-by-one sprintf overflow
in the error and status file name initialization code.

The stack corruption makes megahal reliably crash for me on amd64 every
time it tries to load a saved dictionary.

However, the original problem is on i386 and happens earlier in the
initialization code. I can't reproduce it myself, but I think it might
well be caused by the sprintf overflow. Note that Neil's strace in

 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;filename=megahal.trace.log;att=1;bug=454212

has

 open(/home/nmcgovern/.megahal/megahal.logi, O_WRONLY|O_APPEND|O_CREAT, 0666) 
= 3

and

-rw-r--r--  1 nmcgovern users  380 2007-12-19 11:37 megahal.logi?

while the intended filename is megahal.log. So there's definitely at
least some corruption happening here.

Could somebody (Neil?) try if the bug persists with this patch?



Confirmed that this patch fixes the issue, at least on the version in Etch.

This issue probably qualifies for a stable point update (-release in 
cc). I can prepare a package if you want.


Cheers,
Neil
--
Neil McGovern
SQA - Amino Communications



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#454212: megahal segfaults as soon as it's launched

2008-02-10 Thread Niko Tyni
 Confirmed using etch i386 (though an amd64 processor). Attached output
 of megahal and strace.

The attached patch fixes a stack corruption issue on 64-bit architectures
(reading 8 bytes into a 4-byte buffer) and an off-by-one sprintf overflow
in the error and status file name initialization code.

The stack corruption makes megahal reliably crash for me on amd64 every
time it tries to load a saved dictionary.

However, the original problem is on i386 and happens earlier in the
initialization code. I can't reproduce it myself, but I think it might
well be caused by the sprintf overflow. Note that Neil's strace in

 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;filename=megahal.trace.log;att=1;bug=454212

has

 open(/home/nmcgovern/.megahal/megahal.logi, O_WRONLY|O_APPEND|O_CREAT, 0666) 
= 3

and

-rw-r--r--  1 nmcgovern users  380 2007-12-19 11:37 megahal.logi?

while the intended filename is megahal.log. So there's definitely at
least some corruption happening here.

Could somebody (Neil?) try if the bug persists with this patch?

Cheers,
-- 
Niko Tyni   [EMAIL PROTECTED]
diff --git a/megahal.c b/megahal.c
index 9d4b3ae..cfb1bbc 100644
--- a/megahal.c
+++ b/megahal.c
@@ -417,7 +417,7 @@ void megahal_initialize(void)
 errorfp = stderr;
 statusfp = stdout;
 
-filenamebuff = (char *) malloc (strlen (directory) + 12);
+filenamebuff = (char *) malloc (strlen (directory) + strlen(SEP) + 12);
 
 sprintf(filenamebuff, %s%s%s, directory, SEP, errorfilename);
 initialize_error(filenamebuff);
@@ -1384,7 +1384,7 @@ void save_dictionary(FILE *file, DICTIONARY *dictionary)
 void load_dictionary(FILE *file, DICTIONARY *dictionary)
 {
 register int i;
-int size;
+BYTE4 size;
 
 fread(size, sizeof(BYTE4), 1, file);
 progress(Loading dictionary, 0, 1);