[PATCH] xkb: Fix use of uninitalised memory upon second keyboard init

[Dan Nicholson]

On Wed, Feb 25, 2009 at 9:52 PM, Benjamin Close
<Benjamin.Close at clearchain.com> wrote:
> When allocating a second keyboard structure xkbGetRulesDflt
> is called to get the defaults for rmlvo.
>
> With the second keyboard instance these defaults
> were the values previously allocated in the first call to
> XkbSetRulesDflt; rmlvo is then assigned this value.
>
> rmlvo is then passed into InitKeyboardDeviceStruct which in turn
> calls xkbSetRulesDflt. xkbSetRulesDflts did:
>
>    if( xkbRulesDflt )
>         _XkbFree(XkbRulesDflt);
>         XkbRulesDflt= (rmlvo->rules?_XkbDupString(rmlvo->rules):NULL);
>
> Problem was by freeing XkbRulesDflt, rmlvo->rules was also freed
> hence the dup returned bogus data.
>
> Fix this problem for both the Dflts and the Used cases.
>
> Signed-off-by: Benjamin Close <Benjamin.Close at clearchain.com>

Hmm, that is an issue. It sucks that passing a XkbRMLVOSet to
InitKeyboardDeviceStruct or XkbSetRulesDflts means it _may_ get
destroyed without your knowledge.

Perhaps it would be better if XkbGetRulesDflts would dup the fields so
that you don't have a XkbRMLVOSet with pointers to internal XKB state.
That unfortunately means that you have to free the XkbRMLVOSet or leak
it.

I don't know. You're patch seems to be needed with the current
XkbGetRUlesDflts behavior. Maybe it would be best to just add
(XkbRulesUsed == rmlvo->rules) type checks and not do anything in that
case. Then you won't free the caller's data or leak.

--
Dan