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

[Frederic LE FOLL (JIRA)]

Frederic LE FOLL created ASTERISK-25506:
-------------------------------------------

             Summary: 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)