BUG: maxfwd module incorrectly decrements header twice if the max-forwards… #3511
Conversation
… header is already parsed
There was a problem hiding this comment.
Renamed the macros from MAXWD to MAXFWD also some of the changes here are whitespace changes to be consistent
| return -1; | ||
| } | ||
| } else if (IS_MAXWD_STORED(msg)) { |
There was a problem hiding this comment.
The else/if is removed here in favour of an if after this is so that we can do the trimlen in one place just before checking if IS_MAXFWD_STORED which it will be when using sipmsg_validate assuming it is non zero value so we trim and then check and retrieve the value
| x = str2s( foo->s,foo->len,&err); | ||
| if (err){ | ||
| LM_ERR("unable to parse the max forwards number\n"); | ||
| parsed_val = str2s(mf_value->s, mf_value->len, &err); |
There was a problem hiding this comment.
Assume in this scenario that IS_MAXFWD_STORED failed because either we don't have a value in the parsed field because maxfwds module is the first instance of setting this value or that sipmsgops has not validated the SIP headers so we parse the body, we can only get here if the header has been parsed and if it is actually zero we can just return it
davidtrihy-genesys
changed the title
|
Any updates here? No progress has been made in the last 30 days, marking as stale. |
Summary
Solves an issue where using the
maxfwdmodule functionmf_process_maxfwd_headercan incorrectly double decrement the header value ifsipmsg_validatefunction with flaghis called before calling the aforementioned functionDetails
This is a bug fix which should prevent future issues when using maxfwd which assumes that the
parsedvalue inhdr_fieldwill only ever be used by the maxfwds module which can cause an incorrect double decrement of the header value if some other module was the set theparsedmemory to something other thannullSolution
The
maxfwdmodule has two macros defined which store and fetch the value of theparsedproperty of themaxforwardsheader in the SIP Message, when storing it stores it adding 1 to the value and when fetching it subtracts 1 from the value. This is because this memory block is a void* and 0 represents a null pointer.A problem arises when using
sipmsg_validateto validate the headers, it will parse the value of the header into theparsedfield and when maxfwds checks for the value it assumes it has already been added by the module which adds 1 to the value so when it fetches the value it will then subtract 1 from it causing the double decrement of the value.The solution is a partial rewrite of the module where the addition and subtraction logic in the macro is removed in favour of assuming a value of 0 and a null value act exactly the same anyway so when the header is parsed and the value is 0 then we can just try and parse it from the body again anyway and end up with a value of 0 again but if the value is greater than 0 then we can just fetch the value in the parsed field and return, the trim logic which gets the string representation is called in all cases before checking if the value exists in the parsed header and/or fetching it. We can assume that if we get to trim stage then the header has a body at this stage
Compatibility
No compatibility issues, in fact it fixes a compatibility issue with sipmsgops and maxfwds