[asterisk-bugs] [JIRA] (ASTERISK-25612) Configuration parser handles unsigned integers as signed integers

Asterisk Team (JIRA) noreply at issues.asterisk.org
Sat Dec 5 15:26:33 CST 2015


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

Asterisk Team commented on ASTERISK-25612:
------------------------------------------

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].

> Configuration parser handles unsigned integers as signed integers
> -----------------------------------------------------------------
>
>                 Key: ASTERISK-25612
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25612
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 13.6.0
>            Reporter: Gianluca Merlo
>
> Hello,
> I seem to have stumbled in what seems to be a bug in Asterisk's configuration parser, more specifically it seems that if an option is registered with the unsigned integer type, it is nonetheless handled as if the value should be a signed integer.
> To help you reproduce this issue, I can consistently experience it while trying to configure {{res_hep.so}} via its configuration file {{hep.conf}}. One of {{hep.conf}} options is {{capture_id}} which is intended to be an unsigned integer. {{res/res_hep.c}} registers the option on load with
> {code}
> aco_option_register(&cfg_info, "capture_id", ACO_EXACT, global_options, "0", OPT_UINT_T, 0, STRFLDSET(struct hepv3_global_config, capture_id));
> {code} 
> however, if I configure
> {noformat}
> capture_id = 2147483648
> {noformat}
> the module fails to load and I get (logs):
> {noformat}
> [Dec  5 21:59:16] DEBUG[5547] config.c: extract int from [0] in [-2147483648, 2147483647] gives [0](0)
> [Dec  5 21:59:16] DEBUG[5547] config.c: Parsing /etc/asterisk/hep.conf
> [Dec  5 21:59:16] DEBUG[5547] config.c: extract int from [2147483648] in [-2147483648, 2147483647] gives [0](1)
> [Dec  5 21:59:16] ERROR[5547] config_options.c: Error parsing capture_id=2147483648 at line 31 of
> [Dec  5 21:59:16] ERROR[5547] config_options.c: In hep.conf: Processing options for general failed
> {noformat}
> Regarding the source, and the fix for it, it seems to me that the bug is in the code of {{main/config_options.c}}, in the implementation of {{uint_handler_fn()}}. This functions initializes parser flags as
> {code}
> unsigned int flags = PARSE_INT32 | opt->flags;
> {code}
> while it should initialize them as
> {code}
> unsigned int flags = PARSE_UINT32 | opt->flags;
> {code}
> I hope my guess is right, and you can confirm and fix it in the next release. Thank you for your assistance.



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



More information about the asterisk-bugs mailing list