+++ This bug was initially created as a clone of Bug #12653 +++
Details on an issue in apache-commons-fileupload were released on February 6:
As tomcat (tomcat7) bundles it, it is also affected. It will be fixed in version 7.0.51, when released. There is also a link to the upstream revision that fixes the issue on the tomcat7 security page:
This CVE might be split, as was requested here:
Steps to Reproduce:
The issue is fixed upstream in Tomcat 7.0.52, which doesn't build.
I tried building tomcat 7.0.52 locally in Mageia 4 and got:
/home/david/tomcat/BUILD/apache-tomcat-7.0.52-src/build.xml:1784 The java.7.home property must be set for javadoc build
I found the upstream commit in tomcat to fix this:
The tomcat commit applies cleanly to tomcat 7.0.47 in Mageia 4 and Cauldron, and only needed one "public" removed to apply to 7.0.41 in Mageia 3. I added it in SVN and built it.
The QA team has determined that tomcat in Mageia 4 is not working:
Just for the sake of posterity, the Mageia 3 tomcat update might also fix CVE-2013-1976, as I indicated here:
I'm not *sure* whether it was affected, so I didn't mention it in the advisory.
Here is the basis of the advisory we can use once this is fixed.
Updated tomcat packages fix security vulnerability:
It was discovered that the Apache Commons FileUpload package for Java could
enter an infinite loop while processing a multipart request with a crafted
Content-Type, resulting in a denial-of-service condition (CVE-2014-0050).
Tomcat 7 includes an embedded copy of the Apache Commons FileUpload package,
and was affected as well.
Updated packages in core/updates_testing:
tomcat in mga4 fixed:
works on mga3 x86_64 and mga4 x86_64
tested by installing the tomcat-webapps and confirming the examples work
Testing complete mga3 32
Testing complete mga4 32
Advisory uploaded. Validating (really)
Could sysadmin please push to 3 & 4 updates