Bug 962221

Created attachment 746929 [details]
File: backtrace

Created attachment 746930 [details]
File: cgroup

Created attachment 746931 [details]
File: core_backtrace

Created attachment 746932 [details]
File: dso_list

Created attachment 746933 [details]
File: environ

Created attachment 746934 [details]
File: limits

Created attachment 746935 [details]
File: maps

Created attachment 746936 [details]
File: open_fds

Created attachment 746937 [details]
File: proc_pid_status

Created attachment 746938 [details]
File: var_log_messages

Created attachment 746939 [details]
bad input

My guess is that the U+001C and U+001D in the input are what's causing par to freak out.

When I run par in valgrind with this input, I get some invalid reads and writes:

[uckelman@scylla par]$ valgrind --tool=memcheck --leak-check=full --track-origins=yes par <foo
==14316== Memcheck, a memory error detector
==14316== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==14316== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==14316== Command: par
==14316== 
==14316== Invalid write of size 8
==14316==    at 0x4A0A38D: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:882)
==14316==    by 0x404A9F: reformat (string3.h:51)
==14316==    by 0x401A74: main (par.c:896)
==14316==  Address 0x4c48140 is 288 bytes inside a block of size 292 alloc'd
==14316==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14316==    by 0x4049A0: reformat (reformat.c:497)
==14316==    by 0x401A74: main (par.c:896)
==14316== 
==14316== Invalid write of size 4
==14316==    at 0x404C2F: reformat (reformat.c:544)
==14316==    by 0x401A74: main (par.c:896)
==14316==  Address 0x4c48148 is 4 bytes after a block of size 292 alloc'd
==14316==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14316==    by 0x4049A0: reformat (reformat.c:497)
==14316==    by 0x401A74: main (par.c:896)
==14316== 
==14316== Invalid read of size 4
==14316==    at 0x4A0C014: wcslen (mc_replace_strmem.c:1600)
==14316==    by 0x3257455D9B: vfwprintf (vfprintf.c:1615)
==14316==    by 0x32575097CD: __fwprintf_chk (fwprintf_chk.c:36)
==14316==    by 0x401AA6: main (wchar2.h:347)
==14316==  Address 0x4c48144 is 0 bytes after a block of size 292 alloc'd
==14316==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14316==    by 0x4049A0: reformat (reformat.c:497)
==14316==    by 0x401A74: main (par.c:896)
==14316== 
==14316== Invalid read of size 4
==14316==    at 0x3257470550: _IO_wdefault_xsputn (wgenops.c:352)
==14316==    by 0x32574726E0: _IO_wfile_xsputn (wfileops.c:965)
==14316==    by 0x3257455E6C: vfwprintf (vfprintf.c:1615)
==14316==    by 0x32575097CD: __fwprintf_chk (fwprintf_chk.c:36)
==14316==    by 0x401AA6: main (wchar2.h:347)
==14316==  Address 0x4c48144 is 0 bytes after a block of size 292 alloc'd
==14316==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14316==    by 0x4049A0: reformat (reformat.c:497)
==14316==    by 0x401A74: main (par.c:896)
==14316== 
Blah blah donate blah blah blah blah blah. Blah blah blah blah blah blah
blah.
==14316== 
==14316== HEAP SUMMARY:
==14316==     in use at exit: 0 bytes in 0 blocks
==14316==   total heap usage: 84 allocs, 84 frees, 7,063 bytes allocated
==14316== 
==14316== All heap blocks were freed -- no leaks are possible
==14316== 
==14316== For counts of detected and suppressed errors, rerun with: -v
==14316== ERROR SUMMARY: 5 errors from 4 contexts (suppressed: 2 from 2)

These aren't normal characters to have in text, but nonetheless, par should not crash.

More useful output from valgrind when I build par with debugging symbols (including all patches from the SRPM):

[uckelman@scylla par]$ valgrind --tool=memcheck --leak-check=full --track-origins=yes Par152/par <foo 
==14774== Memcheck, a memory error detector
==14774== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==14774== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==14774== Command: Par152/par
==14774== 
==14774== Invalid write of size 8
==14774==    at 0x4A0A38D: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:882)
==14774==    by 0x40590B: reformat (reformat.c:518)
==14774==    by 0x4042F4: main (par.c:892)
==14774==  Address 0x4c48140 is 288 bytes inside a block of size 292 alloc'd
==14774==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14774==    by 0x405711: reformat (reformat.c:497)
==14774==    by 0x4042F4: main (par.c:892)
==14774== 
==14774== Invalid write of size 4
==14774==    at 0x405B79: reformat (reformat.c:544)
==14774==    by 0x4042F4: main (par.c:892)
==14774==  Address 0x4c48148 is 4 bytes after a block of size 292 alloc'd
==14774==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14774==    by 0x405711: reformat (reformat.c:497)
==14774==    by 0x4042F4: main (par.c:892)
==14774== 
==14774== Invalid read of size 4
==14774==    at 0x4A0C014: wcslen (mc_replace_strmem.c:1600)
==14774==    by 0x3257455D9B: vfwprintf (vfprintf.c:1615)
==14774==    by 0x325746F476: fwprintf (fwprintf.c:34)
==14774==    by 0x40433C: main (par.c:899)
==14774==  Address 0x4c48144 is 0 bytes after a block of size 292 alloc'd
==14774==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14774==    by 0x405711: reformat (reformat.c:497)
==14774==    by 0x4042F4: main (par.c:892)
==14774== 
==14774== Invalid read of size 4
==14774==    at 0x3257470550: _IO_wdefault_xsputn (wgenops.c:352)
==14774==    by 0x32574726E0: _IO_wfile_xsputn (wfileops.c:965)
==14774==    by 0x3257455E6C: vfwprintf (vfprintf.c:1615)
==14774==    by 0x325746F476: fwprintf (fwprintf.c:34)
==14774==    by 0x40433C: main (par.c:899)
==14774==  Address 0x4c48144 is 0 bytes after a block of size 292 alloc'd
==14774==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14774==    by 0x405711: reformat (reformat.c:497)
==14774==    by 0x4042F4: main (par.c:892)
==14774== 
Blah blah donate blah blah blah blah blah. Blah blah blah blah blah blah
blah.
==14774== 
==14774== HEAP SUMMARY:
==14774==     in use at exit: 0 bytes in 0 blocks
==14774==   total heap usage: 84 allocs, 84 frees, 7,063 bytes allocated
==14774== 
==14774== All heap blocks were freed -- no leaks are possible
==14774== 
==14774== For counts of detected and suppressed errors, rerun with: -v
==14774== ERROR SUMMARY: 5 errors from 4 contexts (suppressed: 2 from 2)

Will you be able to investigate and come up with a patch?  I won't have time for a while.

I was hoping you were more familiar with the code than I am, and you would see the easy fix to make. :)

Since sizeof(wchar_t) == 4 for me, and all of the invalid reads and writes valgrind finds go 4 bytes beyond the end of the allocated space, I'm guessing that everything here is caused by an off-by-one bug someplace, which is somehow triggered by the presence of the two unusual control characters.

It might be a while before working on this bubbles up to the top of my heap. (The previous problem affected me a lot more.) Then again, I might fix it tomorrow in a fit of pique. Who knows?

Sorry, you've already spent far more time in this code than I have :-)

Just to note that without the i18n patches, it doesn't seg fault and valgrind doesn't report any issues.

Thanks for checking that. I'll bet those two control characters are being misclassified/miscounted by something handling wide characters.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Moved to Fedora 20.

par-1.52-14.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/par-1.52-14.fc21

Found it:
-    q1 = malloc((linelen + 1) * sizeof (wchar_t));
+    /* Added w1->length to provide space for non-printable characters. */
+    q1 = malloc((linelen + w1->length + 1) * sizeof (wchar_t));

at reformat.c:497.  I'm submitting updates for fc20 and fc21.

par-1.52-14.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/par-1.52-14.fc20

par-1.52-15.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/par-1.52-15.fc21

par-1.52-15.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/par-1.52-15.fc20

I went with a better fix:
-    q1 = malloc((linelen + 1) * sizeof (wchar_t));
+    /* Added w1->length to provide space for multibyte characters. */
+    q1 = malloc((linelen + (w1 ? w1->length : 0) + 1) * sizeof (wchar_t));

par-1.52-15.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/par-1.52-15.fc19

Package par-1.52-15.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing par-1.52-15.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-17632/par-1.52-15.fc19
then log in and leave karma (feedback).

par-1.52-15.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

par-1.52-15.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

par-1.52-15.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Still buggy with multibyte characters, see below.  I am removing all of the par_1.52-i18n patches.

$ printf '\xe2\x97\x8f' | valgrind ./par
==2265== Memcheck, a memory error detector
==2265== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==2265== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==2265== Command: ./par
==2265== 
==2265== Conditional jump or move depends on uninitialised value(s)
==2265==    at 0x4036B2: setaffixes (par.c:696)
==2265==    by 0x404257: main (par.c:892)
==2265== 
==2265== Conditional jump or move depends on uninitialised value(s)
==2265==    at 0x404EDD: reformat (reformat.c:358)
==2265==    by 0x404349: main (par.c:902)
==2265== 
==2265== 
==2265== HEAP SUMMARY:
==2265==     in use at exit: 0 bytes in 0 blocks
==2265==   total heap usage: 80 allocs, 80 frees, 6,144 bytes allocated
==2265== 
==2265== All heap blocks were freed -- no leaks are possible
==2265== 
==2265== For counts of detected and suppressed errors, rerun with: -v
==2265== Use --track-origins=yes to see where uninitialised values come from
==2265== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

par-1.52-16.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/par-1.52-16.fc21

Package par-1.52-16.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing par-1.52-16.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-0536/par-1.52-16.fc21
then log in and leave karma (feedback).

par-1.52-16.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.