Race condition in static file handling

[mkoegler]

com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor adds mapping for not yet accessed static files by calling:

• _webapp.addMappingTarget(path.toString(), fwrapper);
• WebContainer.addToCache(httpRequest, fwrapper, this._webapp);

_webapp.addMappingTarget uses com.ibm.ws.webcontainer.util.URIMatcher.put.
This uses ClauseNode.add, which has a race condition:

`

public ClauseNode add(ClauseNode node) throws Exception {

    // check to see if node already exists
    ClauseNode n = null;

    n = children.get(node.getClause()); // PM06111

    if (n != null) {
        // node already exists
        if (node.getTarget() != null) {
            if (n.getTarget() != null) {
                throw new Exception("Mapping clash for " + node.getTarget() + ": Target " + n.getTarget() + " already exists at node " + cl);
            } else
                n.setTarget(node.getTarget());
        }
        return n;
    }

    children.add(node.getClause(), node); // PM06111
    return children.get(node.getClause()); // PM06111
}

`
It first checks, if the target does not exists and sets the value afterwards without beeing synchronized. This means, two concurrent calls for the same object might both succeed without a clash exception.

WebContainer.addToCache only registers the object, if there is not already a mapping for the entry. Using the race condtion above, it is possible, that _webapp.addMappingTarget succeds for two concurrent request with only one of them stored in the webapp and the WebContainer.addToCache of the other requests runs first (and the addToCache of the first request yields to a duplicate).

During destruction of the webapp, a list of IServletWrapper in WebApp.requestMapper is destroyed. Destroying of a ServletWrapper invalidates all ServletReferenceListener associated with it thereby unregistering the associated WebContainer cache mappings. If the situation above occured, destroy will be called on the first ServletWrapper object. As the second object is registed to the webcontainer cache, the second object is only associated with a CachedServletWrapper - therefore calling destroy on the first object will not invalidate the cache mapping and the second object is not destroyed. This will leaf stale cache mappings in Webcontainer - likely leading to a SRVE0095I.