coheigea commented on PR #3444:
URL: https://github.com/apache/cxf/pull/3444#issuecomment-5569209192
@reta Can you check these comments please:
High: the vulnerable @FormParam path remains unchanged.
The PR limits reads only inside FormEncodingProvider. However, ordinary
@FormParam processing is handled directly by JAXRSUtils.processFormParam, which
still does:
FormUtils.readBody(entityStream, enc) using the uncapped overload.
FormUtils.populateMapFromString(...).
postBody.split("&") before the parameter-count check.
Relevant unchanged paths:
JAXRSUtils.java:1201
FormUtils.java:119
FormUtils.java:137
Therefore, an endpoint using @FormParam can still receive an unbounded body
and reach the original split-before-check allocation. The PR's
formParamsMaxSize setter is not applied to this path.
The servlet request adapter has the same issue:
HttpServletRequestFilter.java:122
Medium: the new provider-side size limit still permits excessive memory
allocation.
The changed provider path now calls the capped overload, but its default is
100 MiB. readBody materializes the body into a ByteArrayOutputStream, then
creates another byte array with toByteArray(), and then creates a decoded
String. A request near the configured limit can therefore require substantially
more than 100 MiB of transient memory before the parser rejects it.
Also, IOUtils.copy writes the input chunk before checking whether maxSize
has been exceeded:
IOUtils.java:218
This is a bounded allocation compared with the original unbounded behavior,
but it is not a robust low-memory default. On a 128 MiB heap, a body
approaching the 100 MiB default can still cause memory pressure or
OutOfMemoryError.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
