https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WONTFIX |---
Status|RESOLVED |REOPENED
--- Comment #12 from Mark Thomas <ma...@apache.org> ---
Now the associated CVEs are public, it can be revealed that this change was in
response to CVE-2025-48976 and CVE-2025-48988.
Combined, these CVEs could trigger an OOME leading to a DoS.
With a carefully crafted request, the memory usage is:
Part Header Size (was 10kB, now 512)
x
Maximum number of Parts per request (was 1000, now 10)
x
Maximum number of concurrent request (8192)
x
2 (due to the internal implementation)
x
2 (if running on Java 8 - so Tomcat 9 only)
That made the worst case memory usage 10kb x ~1k x 8k x 4 = 320Gb
The changes we introduced reduced this to a more manageable 0.5k x 10 x 8k x 4
= 160Mb
Yes, the part limit of 10 is too low for some use cases but increasing it to
100 is probably going to far.
Happy to discuss how we can improve things for the July release round. A few
options to consider for starters:
a) We could make the default maxPartCount 20 by default but halve it for Tomcat
9 if running on Java 8.
b) Increase maxPartCount to something else. Options here depend on what we
consider to be reasonable for default memory requirements. If we think 1Gb is
reasonable maxPartCount could go as high as 60 (or 120 if we include optional
a) as well)
c) include part headers in the maxPostSize calculation? With a 2Mb default that
leads to around 16Gb memory usage which is too high. maxPostSize would need to
come down to ~200k for that to work - that might be too low for a default.
What do folks think?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
