Bug ID 510034: Access Policy memory is not cleared between access policy executions

Last Modified: Nov 22, 2021

Bug Tracker

Affected Product:  See more info
BIG-IP APM(all modules)

Known Affected Versions:
11.5.0, 11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.10, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3,,,,, 11.6.4, 11.6.5,,,

Opened: Mar 02, 2015
Severity: 4-Minor


APD has a Tcl interpreter that can process commands provided inside an Access policy, for variable assignment or other purposes. The Tcl environment provided does not reliably clear Tcl variables assigned in prior executions, so care must be taken to initialize the potentially dirty variables if they are used.


Unexpected results from Access Policy execution.


User uses some Tcl variables that can potentially be not initialized. For example, a variable assign: session.test = regexp {(.+)@example.com} "[mcget {session.logon.last.username}]" foo captured; return $captured Note that here, the regex may match or not match depending on the user input. If it does not match, the variable "captured" *may* contain the results from a different user who logged in previously.


To work around the problem, any variable that was used must be checked. For example, instead of the regex statement above, this could be used: if { [regexp {(.+)example.com} "[mcget {session.logon.last.username}]" foo captured] == 1 } { return $captured; } else { return "nomatch"; } This way, if the regex does NOT match, then the result will be "nomatch" instead of potentially containing results from a previous session.

Fix Information


Behavior Change