Bug 706203 - (CVE-2011-1928) CVE-2011-1928 apr: DoS flaw in apr_fnmatch() due to fix for CVE-2011-0419
CVE-2011-1928 apr: DoS flaw in apr_fnmatch() due to fix for CVE-2011-0419
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 703519 703521 706350 706351 706352 795917
  Show dependency treegraph
Reported: 2011-05-19 14:24 EDT by Vincent Danen
Modified: 2015-11-24 09:38 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-04-10 05:45:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
upstream patch (968 bytes, patch)
2011-05-19 14:25 EDT, Vincent Danen
no flags Details | Diff

  None (edit)
Description Vincent Danen 2011-05-19 14:24:16 EDT
A flaw was discovered in the apr_fnmatch() function in the Apache Portable Runtime (APR) library 1.4.4 (or any backported versions that contained the upstream fix for CVE-2011-0419).  This could cause httpd workers to enter a hung state (100% CPU utilization).
Comment 1 Vincent Danen 2011-05-19 14:25:42 EDT
Created attachment 499921 [details]
upstream patch

Patch provided by upstream to correct this issue.
Comment 2 Vincent Danen 2011-05-19 14:33:47 EDT
This is actually public already:

Comment 4 Vincent Danen 2011-05-19 15:24:11 EDT
This is CVE-2011-1928.
Comment 9 Tomas Hoger 2011-05-20 08:28:27 EDT
This problem is triggered when using APR_FNM_PATHNAME flag.  This is not used by mod_autoindex, so this problem is not triggered in the same way as the original problem CVE-2011-0419 (bug #703390).

In certain configurations, this can be triggered by an HTTP request that does not need to be purposefully malicious.  Upstream bug mentions following example:

  <Location "/*/WEB-INF/">

This problem can be mitigated by wildcards ('*' or '(dir1|dir2|dir3)' alternatives specifications) in the <Location> URL specifications, or using regular expression specifications instead (using <Location ~ > or <LocationMatch>).

If you're temporarily downgrading to older apr version, consider applying CVE-2011-0419 mitigation as mentioned in bug #703390, comment #7.
Comment 10 errata-xmlrpc 2011-05-31 11:45:47 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 4
  Red Hat Enterprise Linux 6

Via RHSA-2011:0844 https://rhn.redhat.com/errata/RHSA-2011-0844.html
Comment 11 Tom 2011-07-19 09:40:43 EDT
I added some details at the related Fedora page at https://bugzilla.redhat.com/show_bug.cgi?id=714182 But the general idea is that nist.gov says that version 2.2.17 and 2.2.18 is affected by combining these CVE:


So even if the exploit doesn't exist in a patched 2.2.17 or 2.2.18 at least one vulnerably scanner company is being a pain about it.

Sorry, I don't know if it is possible for you to get NIST to change the text.


It seems to me the only resolution is to move to 2.2.19

Note You need to log in before you can comment on or make changes to this bug.