libPGF memory leaks

Hi,

I just found dangerous code in libPGF. It uses realloc() and assigns the
result of the realloc function directly to the pointer it wants to resize. The
problem is that if this fails for some reason, the original memory location is
unreachable and will result in a memory leak. There is no way to free this
memory afterwards.
So a tmp pointer must be used, which will hold the new adress (or NULL if it
fails). We can then check for a valid pointer and reassign the pointer to the
original pointer variable.
If it failed, we can free the original pointer variable (or keep it and try to
realloc again).

Is this version of libPGF still in developement?
If not, I'd like to fix this locally, otherwise we should contact the author.

I added an example patch to the mail, there might be more issues in the code
though.

Andi

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Ok the rest of our code base uses either x_realloc (own implementation in
lensfun) or g_realloc (from glib).
So actually we only need to fix the code mentioned in the patch.


Andi Clemens
-----------------
www.digikam.org

On Sunday 21 November 2010 13:40:23 Andi Clemens wrote:

> Hi,
>
> I just found dangerous code in libPGF. It uses realloc() and assigns the
> result of the realloc function directly to the pointer it wants to resize.
> The problem is that if this fails for some reason, the original memory
> location is unreachable and will result in a memory leak. There is no way
> to free this memory afterwards.
> So a tmp pointer must be used, which will hold the new adress (or NULL if
> it fails). We can then check for a valid pointer and reassign the pointer
> to the original pointer variable.
> If it failed, we can free the original pointer variable (or keep it and try
> to realloc again).
>
> Is this version of libPGF still in developement?
> If not, I'd like to fix this locally, otherwise we should contact the
> author.
>
> I added an example patch to the mail, there might be more issues in the
> code though.
>
> Andi

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

libpgf in digiKam core is already a stable code, not development.

There is a patch applied in digiKam core not yet applied in libpgf
about endianness. PGF author is already in CC of this problem and
patch is under way to be integrated in th library.

I recommend to open a new file in BKO, to attch your patch and i will
CC PGF author for review.

Gilles

2010/11/21 Andi Clemens <[hidden email]>:

> Ok the rest of our code base uses either x_realloc (own implementation in
> lensfun) or g_realloc (from glib).
> So actually we only need to fix the code mentioned in the patch.
>
>
> Andi Clemens
> -----------------
> www.digikam.org
>
> On Sunday 21 November 2010 13:40:23 Andi Clemens wrote:
>> Hi,
>>
>> I just found dangerous code in libPGF. It uses realloc() and assigns the
>> result of the realloc function directly to the pointer it wants to resize.
>> The problem is that if this fails for some reason, the original memory
>> location is unreachable and will result in a memory leak. There is no way
>> to free this memory afterwards.
>> So a tmp pointer must be used, which will hold the new adress (or NULL if
>> it fails). We can then check for a valid pointer and reassign the pointer
>> to the original pointer variable.
>> If it failed, we can free the original pointer variable (or keep it and try
>> to realloc again).
>>
>> Is this version of libPGF still in developement?
>> If not, I'd like to fix this locally, otherwise we should contact the
>> author.
>>
>> I added an example patch to the mail, there might be more issues in the
>> code though.
>>
>> Andi
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel