pan-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pan-devel] Buffer overflow in pan when parsing .nzb files


From: Pavel Polischouk
Subject: [Pan-devel] Buffer overflow in pan when parsing .nzb files
Date: Wed, 28 May 2008 23:12:22 -0400
User-agent: Thunderbird 2.0.0.14 (X11/20080501)

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 <address@hidden>

Pavel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]