Bug 86543

Summary:	reinterpret_cast of 0xffffffff to pointer does not generate invalid pointer
Product:	LibreOffice	Reporter:	Cesar Eduardo Barros <cesarb>
Component:	Libreoffice	Assignee:	Not Assigned <libreoffice-bugs>
Status:	NEW ---	QA Contact:
Severity:	minor
Priority:	medium	CC:	noelgrandin, qubit, serval2412
Version:	unspecified
Hardware:	All
OS:	All
Whiteboard:	needAdvice
i915 platform:		i915 features:

Description Cesar Eduardo Barros 2014-11-21 22:56:00 UTC

I first noticed this at commit 26f2da07b1c6074e519d28557a3d1d5518ff6cb4.

There are a few places on the LibreOffice codebase where the maximum unsigned 32-bit value (0xffffffff) is cast to a pointer, to be used as some sort of flag value.

While this makes sense for 32-bit (it points to the last byte of the address space, where nothing of use can be found), on 64-bit it points to within usable address space, which might have been allocated by the platform.

What probably prevents this from causing any bug is that 0xffffffff is unaligned, and any sane allocator is going to return an aligned address, so that flag value cannot by accident match a valid object. But even then, it's sloppy.

The flag value should probably be changed to SIZE_MAX or similar, to make it the equivalent of reinterpret_cast<...>(-1) even on 64-bit.

Here are the places I have found:

$ git grep -i -P 'reinterpret_cast.*0xffffffff' master
master:basic/source/runtime/ddectrl.cxx:#define DDE_FREECHANNEL (reinterpret_cast<DdeConnection*>(0xffffffff))
master:include/svtools/grfmgr.hxx:#define GRFMGR_AUTOSWAPSTREAM_NONE      (reinterpret_cast<SvStream*>(0xffffffffUL))
master:include/vcl/dialog.hxx:#define DIALOG_NO_PARENT (reinterpret_cast<vcl::Window*>(0xffffffff))
master:sw/source/core/frmedt/fedesc.cxx:    const SwPageDesc* pFnd, *pRetDesc = reinterpret_cast<SwPageDesc*>(0xffffffff);
master:sw/source/core/frmedt/fedesc.cxx:        if( reinterpret_cast<SwPageDesc*>(0xffffffff) == pRetDesc )

The last one should also use a #define instead of magic numbers.

Comment 1 Julien Nabet 2014-11-23 21:58:41 UTC

Noel: thought you might be interested in this one (see http://cgit.freedesktop.org/libreoffice/core/commit/?id=26f2da07b1c6074e519d28557a3d1d5518ff6cb4)

Comment 2 Robinson Tryon (qubit) 2014-12-22 03:17:18 UTC

(In reply to Cesar Eduardo Barros from comment #0)
> on 64-bit it points to within
> usable address space, which might have been allocated by the platform.
> 
> What probably prevents this from causing any bug is that 0xffffffff is
> unaligned, and any sane allocator is going to return an aligned address, so
> that flag value cannot by accident match a valid object. But even then, it's
> sloppy.

Sounds like a reasonable concern, so I'll change Status -> NEW.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.