This issue was reported by carterkozak in a private chat. I agreed to open a security issue for it, just in case it could become a CVE. Here's his report:
Sorry to direct ping you, I'd really appreciate a quick read (or redirect) on an issue I've encountered that could be considered a denial-of-service vuln in Undertow:
Latest JDKs from the January 18th release (jdk 11.0.18, and I suspect but haven't confirmed on jdk 17.0.6) include this change: https://github.com/openjdk/jdk11u/commit/243a55ef31e9584467482c6159501b5d522a9427#diff-fd78e578d9d538ff23130422a81e277b5482ac752dc158b6dc07737a9c4c3f4bR737-L737
Which I suspect is the cause of an infinite loop in SslConduit here: https://github.com/undertow-io/undertow/blob/d508c1328ba5c1ca228bfcc405f2c6b9321a1139/core/src/main/java/io/undertow/protocols/ssl/SslConduit.java#L1002-L1004
Where we have HandshakeStatus.NEED_WRAP but the status is updated to Status.CLOSED (new in this JDK release) so the loop never terminates.
I believe the resolution is to break out of the loop when we see Status.CLOSED, but depending on whether or not folks want to consider this a vulnerability, I can avoid making a public ticket/PR.
Probably worth a TLDR intro describing that the result is I/O threads stuck in a busy loop so that no progress can be made (server appears to completely hang due to busy-looping i/o threads)
- is incorporated by
WFCORE-6272 CVE-2022-4492 CVE-2023-1108 Upgrade Undertow to 2.3.5.Final