The Novell bug I tried to link in Comment 0 should have been this:
https://bugzilla.suse.com/show_bug.cgi?id=906761

OK, so the PoC in the Novell bug doesn't reliably reproduce the problem (and didn't for me).  The Debian bug has a reliable reproducer here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768369#114

For the last step, just running ./a.out is sufficient to show the problem, you don't need to use gdb.

I've confirmed the issue and the fix on Mageia 4 i586.

Whiteboard: (none) => has_procedure MGA4-32-OK

MGA4-64 on HP Probook 6555b
I got as far as
$ bunzip2 jpeg_write_marker.bin.bz2
$ bunzip2 jpeg_write_scanlines.bin.bz2
$ gcc -g -O0 -fstack-protector-all test-768369.c -ljpeg
$ gdb --args ./a.out
GNU gdb (GDB) 7.6-6.mga4 (Mageia release 4)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-mageia-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/tester4/Downloads/a.out...done.
(gdb) b encode_mcu_huff
Function "encode_mcu_huff" not defined.
Make breakpoint pending on future shared library load? (y or [n])

The bunzip left me with two .bin files, is that OK

CC: (none) => herman.viaene

As I said, for the last step, you don't need the gdb, just simply run "./a.out" and post-update there will be no output.  There's a bunch of output pre-update.

I get:
*** Error in `./a.out': free(): invalid next size (normal): 0x00000000012c7b50 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7243f)[0x7fcc4a44c43f]
/lib64/libc.so.6(+0x79ca7)[0x7fcc4a453ca7]
/lib64/libjpeg.so.8(+0x2c90d)[0x7fcc4a7bb90d]
/lib64/libjpeg.so.8(jpeg_abort+0x15)[0x7fcc4a7a1685]
./a.out[0x401210]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fcc4a3fbc85]
./a.out[0x400a99]
======= Memory map: ========
00400000-00402000 r-xp 00000000 08:09 273880                             /home/tester4/Downloads/a.out
00601000-00602000 r--p 00001000 08:09 273880                             /home/xxxx/Downloads/a.out
00602000-00603000 rw-p 00002000 08:09 273880                             /home/xxxx/Downloads/a.out
012af000-012d0000 rw-p 00000000 00:00 0                                  [heap]
7fcc4a1c4000-7fcc4a1d9000 r-xp 00000000 08:09 1439114                    /usr/lib64/libgcc_s-4.8.2.so.1
7fcc4a1d9000-7fcc4a3d8000 ---p 00015000 08:09 1439114                    /usr/lib64/libgcc_s-4.8.2.so.1
7fcc4a3d8000-7fcc4a3d9000 r--p 00014000 08:09 1439114                    /usr/lib64/libgcc_s-4.8.2.so.1
7fcc4a3d9000-7fcc4a3da000 rw-p 00015000 08:09 1439114                    /usr/lib64/libgcc_s-4.8.2.so.1
7fcc4a3da000-7fcc4a586000 r-xp 00000000 08:09 1439109                    /usr/lib64/libc-2.18.so
7fcc4a586000-7fcc4a785000 ---p 001ac000 08:09 1439109                    /usr/lib64/libc-2.18.so
7fcc4a785000-7fcc4a789000 r--p 001ab000 08:09 1439109                    /usr/lib64/libc-2.18.so
7fcc4a789000-7fcc4a78b000 rw-p 001af000 08:09 1439109                    /usr/lib64/libc-2.18.so
7fcc4a78b000-7fcc4a78f000 rw-p 00000000 00:00 0 
7fcc4a78f000-7fcc4a7d2000 r-xp 00000000 08:09 1446270                    /usr/lib64/libjpeg.so.8.0.2
7fcc4a7d2000-7fcc4a9d2000 ---p 00043000 08:09 1446270                    /usr/lib64/libjpeg.so.8.0.2
7fcc4a9d2000-7fcc4a9d3000 r--p 00043000 08:09 1446270                    /usr/lib64/libjpeg.so.8.0.2
7fcc4a9d3000-7fcc4a9d4000 rw-p 00044000 08:09 1446270                    /usr/lib64/libjpeg.so.8.0.2
7fcc4a9d4000-7fcc4a9e4000 rw-p 00000000 00:00 0 
7fcc4a9e4000-7fcc4aa02000 r-xp 00000000 08:09 1439102                    /usr/lib64/ld-2.18.so
7fcc4abde000-7fcc4abe1000 rw-p 00000000 00:00 0 
7fcc4abfd000-7fcc4ac02000 rw-p 00000000 00:00 0 
7fcc4ac02000-7fcc4ac03000 r--p 0001e000 08:09 1439102                    /usr/lib64/ld-2.18.so
7fcc4ac03000-7fcc4ac04000 rw-p 0001f000 08:09 1439102                    /usr/lib64/ld-2.18.so
7fcc4ac04000-7fcc4ac05000 rw-p 00000000 00:00 0 
7fffb9fd1000-7fffb9ff3000 rw-p 00000000 00:00 0                          [stack]
7fffb9ffe000-7fffba000000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted

Testing on Mageia4x64, real hardware

Following procedure found here :
https://bugs.mageia.org/show_bug.cgi?id=6928#c6

and PoC in Comment 2

From current packages :
---------------------
lib64jpeg8-1.3.0-3.mga4
lib64jpeg62-1.3.0-3.mga4
lib64turbojpeg0-1.3.0-3.mga4
jpeg-progs-1.3.0-3.mga4

Basic testing OK
PoC test resulted in a crash

To updated testing packages :
---------------------------
- jpeg-progs-1.3.0-3.1.mga4.x86_64
- lib64jpeg-devel-1.3.0-3.1.mga4.x86_64
- lib64jpeg-static-devel-1.3.0-3.1.mga4.x86_64
- lib64jpeg62-1.3.0-3.1.mga4.x86_64
- lib64jpeg8-1.3.0-3.1.mga4.x86_64
- lib64turbojpeg0-1.3.0-3.1.mga4.x86_64

Basic testing OK
PoC test still resulted in a crash.

I get the exact same result than Herman.

Testing packages don't solve the bug on Mageia4x64

CC: (none) => olchal

Retried the PoC with current packages and updated testing packages but using gdb.

Could see that in both case it aborts but only with current packages it complains of : *** stack smashing detected ***.

Updated testing packages don't complain of stack smashing anymore.

So maybe they do indeed solve the bug !

Nice catch Olivier!  Sorry about this.  Maybe we just uncovered a different issue.

I e-mailed the people discussing the issue on the Debian bug about it.

DRC from upstream says he can't reproduce the crash issue with the latest upstream code.  Since the stack smashing is fixed, we can OK this update.

Also, Bernhard, the writer of the PoC, had this to say about the crash you saw:
"I am able to reproduce it with the test case I attached to bug 768369.

In my opinion this is the fault of the test case.
It was intended only to demonstrate the stack smashing, so I have
never reached this last clean up function."

Also from Bernhard:
"Hello,
yes that is my fault, I swapped lines 193 and 194 in the testcase.

        jpeg_pixels = (JSAMPLE*)malloc(line_size);
        line_size = jpeg_info.image_width * jpeg_info.input_components * sizeof(JSAMPLE);

Therefore the malloc got a undefined line_size and when cleaning up it crashes.

If you swap the lines then the crash in the test case should go away."

I swapped the lines in test-768369.c as shown in Comment 11 and reran the test case.
Now running a.out simply returns without messages and running
gdb --args ./a.out
returns a gdb session without any error messages.

Whiteboard: has_procedure MGA4-32-OK => has_procedure MGA4-32-OK MGA4-64-OK

Validating, advisory uploaded.

Keywords: (none) => validated_update
Whiteboard: has_procedure MGA4-32-OK MGA4-64-OK => has_procedure MGA4-32-OK MGA4-64-OK advisory
CC: (none) => remi, sysadmin-bugs

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGASA-2014-0544.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED