[improvement]: pbx_variables.c: Prevent infinite recursion and stack overflow with variable expansion

[InterLinked1]

Improvement Description

It is possible to craft dialplan (though not likely intentionally) that will result in an infinite recursion of variable substitution. Currently, Asterisk will just segfault due to stack overflow. This patch detects this and instead safely aborts and logs an error for the user to fix the offending dialplan.

[jcolp]

How does this recursion occur...

[InterLinked1]

How does this recursion occur...

Here's an example:

[lookup-context]
exten => _X,1,Return(1) ; base case
exten => _1X,1,Return(2) ; base case
exten => _N0,1,Return(3) ; base case
exten => _XX,1,Return(${EVAL_EXTEN(${CONTEXT},${EXTEN:-2:1}0,1)}) ; recursive case

[overflow]
exten => s,1,Set(foo=00)
        same => n,NoOp(${EVAL_EXTEN(lookup-context,${foo:-2},1)})
	same => n,Assert(0) ; crashes before it gets here

Correct dialplan shouldn't recurse indefinitely, but exten => _XX,1,Return(${EVAL_EXTEN(${CONTEXT},${EXTEN:-2:1}0,1)}) is bad dialplan since it can recurse on itself. This was a typo and should have actually been _X5, not _XX.

[jcolp]

Ah, through the use of the EVAL_EXTEN dialplan function you added. Would it have been possible prior to the inclusion of that?

[InterLinked1]

Ah, through the use of the EVAL_EXTEN dialplan function you added. Would it have been possible prior to the inclusion of that?

I haven't thought of any cases where it would be, and I suspect maybe not, but I'm not positive.

Recursion with EVAL_EXTEN is not inherently problematic, and as in the (corrected) example above, may even be desired, but it can be easy to shoot yourself in the foot this way - great power but no guardrails.