[jira] [Created] (MTOMCAT-328) Tomcat 9.0.54 and it has openssl-1.1.1l dependency, with Address CVE-2021-4160

2022-02-14 Thread qwer (Jira)
qwer created MTOMCAT-328:


 Summary: Tomcat 9.0.54 and it has openssl-1.1.1l dependency, with 
Address CVE-2021-4160
 Key: MTOMCAT-328
 URL: https://issues.apache.org/jira/browse/MTOMCAT-328
 Project: Apache Tomcat Maven Plugin
  Issue Type: Bug
Reporter: qwer


Tomcat 9.0.54 and it has openssl-1.1.1l dependency, which is 
vulnerable.(https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2021-4160)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 65408] tomcat8.5.X occurs an AssertionError occationally after running for a period of time

2022-02-14 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=65408

--- Comment #15 from Thomas Sartissohn  ---
Some update on this topic. We use the tomcat embeddded version 8.5.x
Since a while we faced the same issue. We see NullPointer exceptions when
working on the response object and java.lang.AssertionErrors when a new request
arrives.

We then finally drilled the issue down to a misconfiguration in our
ThreadPoolExecutor. There the Linkedblocking queue to store the processor
requests in was too small. 
When the queue is too small and the executor is out of threads, any new request
is rejected with an RejectedExecutionException.

This execption is handled in the tomcat and cancelledKey is executed which
recycles the assigned processor. (See stack below)
And here seems there is an issue in the tomcat code somewhere. It happens that
the call of cancelledKeys recycles a processor which is currently in use. This
explains the NullPointer we get when sending the response. The processor was
recycled while we are working on. That is why we are no longer able to send the
response.
But there is also another issue. When we call cancelledKey while the processor
is still in work the processor ends finally twice in the recycledProcessor
stack. We have seen that in the log that the same processor was pushed twice to
the recycledStack without a pop in between.
Also a heap dump showed that the recycledProcessor stack was filled with the
same processor object.

Having the same processor more then once on the recycled stack brings us then
to the AssertionError. When we have two therads getting the same processor out
of the stack we will get the AssertionError.

We fixed the issue with increasing the queue size for the Executor. However
maybe the processor handling should reviewed regarding the cancelledKey event
and pushing the same object more the once to the stack.

The relevant stacks are

2022-02-08T16:33:25.113+ WARN Executor rejected socket for processing
java.util.concurrent.RejectedExecutionException: Task
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor@10842846 rejected from
c.s.ListenerThreadPoolExecutor@4d77f359[Running, pool size = 250, active
threads = 130, queued tasks = 247, completed tasks = 27887]
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2055)
~[?:?]
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:825)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1355)
~[?:?]
at
org.apache.tomcat.util.net.AbstractEndpoint.processSocket(AbstractEndpoint.java:1105)
~[?:?]
at
org.apache.tomcat.util.net.NioEndpoint$Poller.processKey(NioEndpoint.java:896)
~[?:?]
at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:872)
~[?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]


2022-02-08T16:33:25.117+ INFO HTTP Listener Encountered a non-recycled
request and recycled it forcedly.
org.apache.catalina.connector.CoyoteAdapter$RecycleRequiredException: null
at
org.apache.catalina.connector.CoyoteAdapter.checkRecycled(CoyoteAdapter.java:546)
~[?:?]
at org.apache.coyote.http11.Http11Processor.recycle(Http11Processor.java:1578)
~[?:?]
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.release(AbstractProtocol.java:1021)
~[?:?]
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.release(AbstractProtocol.java:1054)
~[?:?]
at
org.apache.tomcat.util.net.NioEndpoint$Poller.cancelledKey(NioEndpoint.java:769)
~[?:?]
at
org.apache.tomcat.util.net.NioEndpoint$Poller.processKey(NioEndpoint.java:906)
~[?:?]
at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:872)
~[?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]

-- 
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



[Bug 65408] tomcat8.5.X occurs an AssertionError occationally after running for a period of time

2022-02-14 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=65408

Konstantin Kolinko  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #16 from Konstantin Kolinko  ---
REOPENING, as Comment 15 has some reproduction recipe that can be triaged.

(In reply to Thomas Sartissohn from comment #15)
> Some update on this topic. We use the tomcat embeddded version 8.5.x


Thomas, do you know what exact version of 8.5.x you use?
(What is the value of 'x'?)

The version number should be visible in a META-INF/MANIFEST.MF file as the
value of 'Implementation-Version' header, or in the
org/apache/catalina/util/ServerInfo.properties file.

-- 
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



[Bug 65408] tomcat8.5.X occurs an AssertionError occationally after running for a period of time

2022-02-14 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=65408

Thomas Sartissohn  changed:

   What|Removed |Added

 CC||t.sartiss...@seeburger.de

--- Comment #17 from Thomas Sartissohn  ---
We face the issue with 8.5.66 and 8.5.75

-- 
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



[jira] [Resolved] (MTOMCAT-328) Tomcat 9.0.54 and it has openssl-1.1.1l dependency, with Address CVE-2021-4160

2022-02-14 Thread Mark Thomas (Jira)


 [ 
https://issues.apache.org/jira/browse/MTOMCAT-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas resolved MTOMCAT-328.
-
Resolution: Invalid

The Maven plugin never released a version for Tomcat 9.

The OpenSSL vulnerability references affects MIPS32 and MIPS64 platforms. Java 
(and hence Tomcat) is not available on those platforms.

> Tomcat 9.0.54 and it has openssl-1.1.1l dependency, with Address CVE-2021-4160
> --
>
> Key: MTOMCAT-328
> URL: https://issues.apache.org/jira/browse/MTOMCAT-328
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Bug
>Reporter: qwer
>Priority: Major
>
> Tomcat 9.0.54 and it has openssl-1.1.1l dependency, which is 
> vulnerable.(https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2021-4160)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org