bug#11442: dbus uses Emacs integer as pointer, possible core dump

bug#11442: dbus uses Emacs integer as pointer, possible core dump

[Paul Eggert]

The trunk version of Emacs src/dbusbind.c contains a function
xd_get_connection_address that does this:

     connection = (DBusConnection *) (intptr_t) XFASTINT (val);

This converts an Emacs integer to a pointer without checking
that it is actually of the proper C type.  It is possible
for Lisp code to mistakenly put an integer there that will
cause Emacs to dump core.  Shouldn't this be made safe, so
that Lisp code can't do that?  For example, a DbusConnection *
could be made a proper Lisp pseudovector or misc type or
something like that.  The idea is to avoid a bad pointer
leaking into the C code.

bug#11442: dbus uses Emacs integer as pointer, possible core dump

[Michael Albinus]

Paul Eggert <eggert@cs.ucla.edu> writes:

Hi Paul,

> The trunk version of Emacs src/dbusbind.c contains a function
> xd_get_connection_address that does this:
>
>     connection = (DBusConnection *) (intptr_t) XFASTINT (val);
>
> This converts an Emacs integer to a pointer without checking
> that it is actually of the proper C type.  It is possible
> for Lisp code to mistakenly put an integer there that will
> cause Emacs to dump core.

In general, I agree with you. In the given case, it is just a pointer
address which has been written in Fdbus_init_bus. No other place is
expected to write such an address, but since it is a Lisp object,
somebody could do by mistake.

>  Shouldn't this be made safe, so that Lisp code can't do that?  For
> example, a DbusConnection * could be made a proper Lisp pseudovector
> or misc type or something like that.  The idea is to avoid a bad
> pointer leaking into the C code.

DbusConnection * is included by <dbus/dbus.h>; we cannot make it a
private type. But if there is something we could add as "glue type",
please do. I'm not so familar with Emacs' internal type armors.

Best regards, Michael.

bug#11442: dbus uses Emacs integer as pointer, possible core dump

[Andreas Schwab]

Michael Albinus <michael.albinus@gmx.de> writes:

> Paul Eggert <eggert@cs.ucla.edu> writes:
>
> Hi Paul,
>
>> The trunk version of Emacs src/dbusbind.c contains a function
>> xd_get_connection_address that does this:
>>
>>     connection = (DBusConnection *) (intptr_t) XFASTINT (val);
>>
>> This converts an Emacs integer to a pointer without checking
>> that it is actually of the proper C type.  It is possible
>> for Lisp code to mistakenly put an integer there that will
>> cause Emacs to dump core.
>
> In general, I agree with you. In the given case, it is just a pointer
> address which has been written in Fdbus_init_bus. No other place is
> expected to write such an address, but since it is a Lisp object,
> somebody could do by mistake.

Why is Vdbus_registered_buses exported to lisp?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#11442: dbus uses Emacs integer as pointer, possible core dump

[Michael Albinus]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> In general, I agree with you. In the given case, it is just a pointer
>> address which has been written in Fdbus_init_bus. No other place is
>> expected to write such an address, but since it is a Lisp object,
>> somebody could do by mistake.
>
> Why is Vdbus_registered_buses exported to lisp?

Indeed, that's the question.

When I wrote the new code for private buses, it was needed in dbus.el
(don't remember the reason). In the final code I've committed,
dbus-registered-buses isn't needed anymore on Lisp level.

I've converted it to be an internal Lisp object. Paul, is this
sufficient from your pov, or do we need more checks?

> Andreas.

Best regards, Michael.

bug#11442: dbus uses Emacs integer as pointer, possible core dump

[Paul Eggert]

On 05/09/2012 02:19 PM, Michael Albinus wrote:
> I've converted it to be an internal Lisp object.

Thanks; that looks good.  Closing the bug.