VTY Crash due an assumption we are breaking

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Wed Aug 11 17:40:09 UTC 2010


On Wed, Aug 11, 2010 at 04:24:35AM +0800, Holger Hans Peter Freyther wrote:
> Hi all,
> I was debugging a crash with the VTY and I am not fully understanding it but I
> can easily reproduce it. The problem is triggered with the new VTY OML code
> and here is what I know.

thanks for pointing this out.

> 1.) we move from ENABLE_NODE to the OML node. and allocate memory
> 2.) when exiting the node we will free the data at vty->index.. and
>     set the pointer to NULL.

yes, that's what it's supposed to do.

> But I can easily produce a double free issue and this seems to be due.

strange...

> cmd_execute_command:
> 	1.) saves the vty->index to oindex and vty->node to onode
> 	2.) tries calling vty_go_parent or such...
> 	3.) tries more stuff...
> 	4.) as stuff failed resets vty->index to oindex...

ah, ok.  I didn't realize that try/revert nature of the vty command execution
when coming up with the application-specific go_parent() callback function.

> so the next exit command will do a double free... and the funny part is that
> the code has one assumption everything > CONFIG_NODE is considered to be
> config as well. 

Yes, this is indeed true.   I didn't really see a clean way to solve this while
generalizing the vty code into libosmovty.

> This means that we should have two enum values in libosmovty,
> one for Last_Enable, one for Last_Config and have enough space between them.

that sound useful.  Or we do something like |= some high bit to indicate it is
a sub-node of enable or config.

> And the other part... maybe vty_go_parent should return CMD_SUCCESS?

I don't really see anybody who uses the result of vty_go_parent(), all
the callers seem to discard the return value.  However, it doesn't seem
right that vty_go_parent does not pass on the retunr value of the
host.app_info->go_parent_cb() function.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the OpenBSC mailing list