Exploit: Crash Server On-Demand - Configuration State Netty Thread Lock

Stack trace

It can be an exploit or big mistake, I think its both. Basically the finish configuration packet makes the netty thread wait. Big mistake, this can be used by attackers and give micro lags for bad connections. Someone with bad connection joins -> half the server freezes for a moment. Exploiter joins -> entire server lags.

It seems like a design flaw:

• I have solved it by not awaiting at all the netty thread and use a memory driven state pipeline processor instead to avoid relying on awaiting the netty thread and only soft-blocking the user instead.
• Await is a cheap and wrong way to "wait until something happens" -> monitor state thread or task instead is more stable and better design and avoids locking a thread used for another thing.

message (5).txt

Plugin and Datapack List

[16:14:42 INFO]: ℹ Server Plugins (20):
[16:14:42 INFO]: Paper Plugins (1):
[16:14:42 INFO]: - PlugManX
[16:14:42 INFO]: Bukkit Plugins (19):
[16:14:42 INFO]: - AuthMe, AuthMePremiumBukkit, EntityLimiter, EssentialsLite, ExploitFixer, FairPlay, HamsterAPI, packetevents, PlaceholderAPI, PlaytimeCrates
[16:14:42 INFO]: RedstoneLimiter, SMPCombat, SMPOrders, SMPPunishments, SMPRegions, StaffModeX, TAB, Vault, ViaVersion

Actions to reproduce (if known)

No response

Folia version

[16:14:59 INFO]: Checking version, please wait...
[16:15:00 INFO]: This server is running Folia version 1.21.11-DEV-ver/1.21.11@3ef0ba6 (1970-01-01T00:00:00Z) (Implementing API version 1.21.11-R0.1-SNAPSHOT)

Other

No response

Start by reviewing the configuration packet handling and the point where the finish configuration packet waits on the Netty thread. Use the supplied stack trace and message.5.txt as initial evidence, then investigate reproduction with a slow connection or a joining client. Done means the reported packet path no longer causes the server-wide lag without blocking the Netty thread.