Comment 2 for bug 2047686

iiuc, the vulnerability is triggered if an nfs:// URL that exploits the regex inefficiency is an image location in glance

I think this can be worked in public as a hardening opportunity for the following reasons (numbered for easy reference by people checking my reasoning here):

1. this can only occur under a specific configuration of cinder (and I think, glance; both must be using an nfs backend, and cinder must be using a netapp nfs backend)

2. if such nfs:// URLs were used in normal operation, this inefficiency would have been discovered already because of undesirable pauses during volume creation

3. thus, an attacker would have to get the code in a position where it processes a "bad" URL

4. the code path occurs in cloning a volume from an image, when the image location is parsed to see if it is usable by the backend

5. OSSN-0090 recommends that end users not be allowed to directly set image locations

6. (further, even if OSSN-0090 is ignored, if the nfs backend isn't enabled in glance, I'm pretty sure the "nfs://" location scheme is rejected and can't be set as an image location)

So, I don't think this exploit should occur "in the wild". That said, I have no objection against hardening the netapp driver; I just think it can be done in public in the normal way.