Review Request 127834: ki18n: Fix theoretically possible use-after-free in gettext when using strict ANSI compilers

[Michael Pyne]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127834/
-----------------------------------------------------------

(Updated May 7, 2016, 7:12 a.m.)


Status
------

This change has been marked as submitted.


Review request for KDE Frameworks, Localization and Translation (l10n) and Chusslove Illich.


Changes
-------

Submitted with commit 639ab84221434d29a2055fa090e14a8b0822779f by Michael Pyne to branch master.


Repository: ki18n


Description
-------

Coverity noted that some of code for message catalog lookup uses some pointer values after they are freed. Even though the use in question is a simple equality comparison against a different (valid) pointer, it is still undefined behavior according to the C (and C++) language specs and is therefore liable to cause miscompilation and who knows what other kinds of problems.

This code is not normally enabled, normally a code path that supports variable-length arrays is active, which is not susceptible to this bug.

Since VLAs are not supported even in current C++ versions, making VLA support mandatory is not feasible, so instead I opted to move the pointer comparisons to a point in the code where the comparison is valid, and then use the saved result later.

I have also reported the bug to GNU Gettext, since upstream still has the error. It is GNU Gettext bug 47847.


Diffs
-----

  src/gettext.h b06fc90 

Diff: https://git.reviewboard.kde.org/r/127834/diff/


Testing
-------

Code compiles and KDE applications still seem to work fine. I also tested with the changed code path forcibly enabled by disabling VLA support, and things still seemed to work.

There's not a lot of autotests to choose from, but the KLocalizedString test still passed.


Thanks,

Michael Pyne

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160507/11ccf430/attachment-0001.html>