[asterisk-bugs] [JIRA] (ASTERISK-25506) CONFBRIDGE failure after an app_confbrige.so module reload

[Asterisk Team (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228047#comment-228047 ] 

Asterisk Team commented on ASTERISK-25506:
------------------------------------------

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

> CONFBRIDGE failure after an app_confbrige.so module reload
> ----------------------------------------------------------
>
>                 Key: ASTERISK-25506
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25506
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_confbridge
>    Affects Versions: 13.6.0
>         Environment: CentOS 6
>            Reporter: Frederic LE FOLL
>            Severity: Minor
>
> Problem description:
> Set(CONFBRIDGE(menu,template)=...) fails after an app_confbrige.so module reload.
> Option 1: segmentation fault.
> Option 2: ERROR and WARNING.
> The messages when no segmentation fault: 
>   "ERROR ... aco_process_var: Error parsing template=xxx at line 0 of CONFBRIDGE"
>   "WARNING ...  func_confbridge_helper: CONFBRIDGE(menu,template) cannot be set to '...'. Invalid type, option, or value."
> How to reproduce:
> extensions.conf:
>   [test]
>   exten=1,1,Set(CONFBRIDGE(menu,template)=xxx) ; where xxx is a menu defined in confbridge.conf
> CLI:
>   > console dial 1 at test
>   [... nothing special here ...]
>   > module reload app_confbridge.so
>   Module 'app_confbridge.so' reloaded successfully.
>       -- Reloading module 'app_confbridge.so' (Conference Bridge Application)
>   CLI> console dial 1 at test
>   ERROR ... aco_process_var: Error parsing template=xxx at line 0 of CONFBRIDGE
>   WARNING ... func_confbridge_helper: CONFBRIDGE(menu,template) cannot be set to 'xxx'. Invalid type, option, or value.
> Analysis:
> Upon "module reload app_confbridge.so", apps/confbridge/conf_config_parser.c:conf_reload_config() is called.
> Long story made short, nice cooperation between conf_config_parser.c, main/config_options.c and  main/config.c:
> 1) aco_process_config() will allocate memory for configuration reload (allocation through confbridge_cfg_alloc()) and store the pointer into confbridge structure field cfg_handle.internal->pending.
> 2) ast_config_load2(), because config file has not changed, will free this "pending" memory (through ast_config_destroy()) and return a "pseudo"-pointer CONFIG_STATUS_FILEUNCHANGED).
> 3) However, CONFBRIDGE(menu,template), processed by menu_template_handler(), will read (through aco_pending_config()) and try to use this "pending" pointer that has not been reset and now points to freed memory. Contents not guaranteed !
> Who uses this "pending" configuration memory in confbridge ? It seems that only menu_template_handler() and verify_default_profiles() use it.
> verify_default_profiles() aims at verifying a new configuration. The use of aco_pending_config() seems logical.
> menu_template_handler() just needs to consult the valid config, just as handle_cli_confgbridge_show_...() functions, for instance.
> Proposal :
> In apps/confbridge/conf_config_parser.c:menu_template_handler(),
> replace: struct confbridge_cfg *cfg = aco_pending_config(&cfg_info);
> with: RAII_VAR(struct confbridge_cfg *, cfg, ao2_global_obj_ref(cfg_handle), ao2_cleanup);
> This allows menu_template_handler() to read configuration just like handle_cli_confgbridge_show_...() functions do, and this fixes the problem : no more core dump, no more "Invalid type, option, or value".



--
This message was sent by Atlassian JIRA
(v6.2#6252)