Buffer overflow in pan when parsing .nzb files

Hi!

I discovered a heap overflow in pan 0.132, part of the code reading .nzb 
files (either from tasks.nzb or elsewhere). Usually it results in 
assertion failure, but in certain cases might lead to segmentation 
fault, arbitrary code execution shouldn't be ruled out either.

The root cause is as follows:
PartsBatch class has inconsistent storage for Parts. For each new batch, 
it does not clear() the 'parts' variable, but only resize()s it if the 
new batch is bigger (pan/data/parts.cc, lines 307 and 316). If the new 
batch is smaller than the previous, extra entries are untouched.

The problem happens when pan attempts to sort the full vector 
(pan/tasks/nzb.cc:128), thus possibly mixing the parts from the current 
batch with the parts from the previous batches.

Parts class later uses the mids from the PartsBatch to fill in a 
combined mids buffer. The pre-allocated size for it is based on the real 
count of part mid sizes, but after sorting the mids of wrong messages 
might get in, and they will have different sizes, often leading to the 
overflow.

The solution is to clear() the 'parts' vector on each init(), then 
push_back() the new parts in add_part, so the vector size always 
corresponds to the real number of found parts. The sort() will then 
always work on correct number of parts.

The bug is tracked in RedHat bugzilla for Fedora 9: 
https://bugzilla.redhat.com/show_bug.cgi?id=446902
There are some stack traces from failed assertion and segmentation 
faults caused by this bug, as well as some trigger .nzb files attached 
to that bugzilla entry.

The proposed patch: https://bugzilla.redhat.com/attachment.cgi?id=306880

Signed-off by: Pavel Polischouk <pavel.polischouk@...>

Pavel