[asterisk-bugs] [JIRA] (ASTERISK-25506) [patch]CONFBRIDGE failure after an app_confbrige.so module reload results in segfault or error/warning messages.

[Friendly Automation (JIRA)]

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

Friendly Automation commented on ASTERISK-25506:
------------------------------------------------

Change 5580 merged by George Joseph:
app_confbridge:  Fix reference to cfg in menu_template_handler

[https://gerrit.asterisk.org/5580|https://gerrit.asterisk.org/5580]

> [patch]CONFBRIDGE failure after an app_confbrige.so module reload results in segfault or error/warning messages.
> ----------------------------------------------------------------------------------------------------------------
>
>                 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
>         Attachments: ASTERISK-25506-conf_config_parser.patch
>
>
> h2. 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."
> h2. How to reproduce:
> extensions.conf:
> {noformat}
>   [test]
>   exten=1,1,Set(CONFBRIDGE(menu,template)=xxx) ; where xxx is a menu defined in confbridge.conf
> {noformat}
> 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.
> h2. 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:
>  # 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.
>  # 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).
>  # 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.
> h2. 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)