The ability to monitor when user code invokes a library function offers numerous advantages. For example, during black-box testing of code, high-level control-flow integrity (CFI) checking, run-time access-control policy enforcement and so on. However, for this technique to be useful it must be efficient and able to function even when the target application is provided only as a statically linked executable. In an earlier paper we demonstrated how library calls may be intercepted using wrappers. But this approach works only with dynamically linked code and requires labour-intensive processing of the function arguments. Under the current scheme, each library - either dynamically or statically linked - constitutes a separate code-region. At any point in time, only pages belonging to that one region are marked as executable, so when code branches to a page outside the `home' region, it will land in a non-executable page, a fault will occur and the kernel will take over. By adding suitable code to the kernel, we can determine (a) whether the call should go ahead, (b) whether the arguments are acceptable and (c) ensure that the kernel will be informed when the code returns from the called function. In this paper we present our technique by analyzing the interception of a known exploit of the NGINX server. We show that our mechanism can detect and contain the attack and discuss the performance overheads of our mechanism.