Bug ID 490681: Memcache entry for dynamic user leaks

Last Modified: Oct 16, 2023

Affected Product(s):
BIG-IP APM(all modules)

Known Affected Versions:
11.5.1 HF1, 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.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.5.3 HF1, 11.5.3 HF2, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.4.1, 11.5.0, 11.5.1, 11.5.2, 11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.1.0 HF1, 12.1.0 HF2, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2

Fixed In:
12.0.0, 11.6.0 HF5, 11.5.3, 11.4.1 HF9

Opened: Nov 13, 2014

Severity: 3-Major

Related Article: K17470

Symptoms

A race condition causes a memcache entry to remain in memcache forever.

Impact

The user state information for the user remains unchanged. If the user is locked out in memcache, the user state remains locked out.

Conditions

Due to a race condition between identifying dynamic users in MySQL and removing them from memcache (based on timestamp), some memcache entries remain. Although the entry is removed from MySQL, it remains in memcache.

Workaround

The only way to recover is to remove the user using telnet to access memcache (which is not a typical operation and is difficult to perform).

Fix Information

Now a self expiry is set for each memcache object (which is configurable). With this change, each user remains in the cache only for the configured duration.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips