Hi L1nq, thanks a lot for these, and for going through the serialization path so carefully.
I've left comments on both (#9075 and #9076), nothing fundamental, mostly around a few details worth tightening. One practical note: we're discussing a release soon, so it would be great to get these in before it goes out, given they're security-relevant. If you can address the review comments in the next few days, I think we have a good shot at including them. Does that timeline work for you? Thanks again for the careful work here. Gruß Richard > Am 04.09.2026 um 15:23 schrieb xxx xxx <[email protected]>: > > Hello everyone, > > I've been doing a security review of Storm's serialization path. It > produced two robustness issues on GitHub that are now filed, and I just > opened a pull request for each. Since PRs don't reach this list by default, > here is a short notification. > > PR #9075 (closes #9073) adds a serial filter for the java serialization > fallback bridge. A new config key, > topology.fall.back.on.java.serialization.filter, holds a JEP-290 pattern > that SerializableSerializer installs on every fallback deserialization, so > the filter is topology-scoped and covers local mode too. conf/defaults.yaml > ships a default deny-list of well-known gadget namespaces plus a 10 MB > maxbytes cap; sites that need the old behavior can override or clear the > key per topology. rzo1 suggested providing a PR for the option (2) > mechanism in the issue thread. This ships that mechanism with the deny-list > enabled by default rather than empty — that choice and its one-line > flip-back are described in the issue thread, and I'm happy to switch it to > an empty default if reviewers prefer. > > PR #9076 (closes #9074) stops undecodable messages from killing the > receiving worker. Today any non-IOException decode failure escapes recv(), > reaches Utils.handleUncaughtException, and the worker exits. The change > wraps each message's deserialization so the known decode-time exception > types drop that one message with an ERROR log and a deserializationFailures > counter, while anything outside the tolerated set keeps today's behavior. > Verified against a live 3.0.1-SNAPSHOT cluster: the same 27-byte frame that > kills a worker on master leaves the worker up and the topology active on > the branch. > > Both carry tests (8 and 9 cases) and neither changes behavior for streams > that decode cleanly. Review and feedback welcome — I'll follow the GitHub > threads. > > https://github.com/apache/storm/pull/9075 > https://github.com/apache/storm/pull/9076 > https://github.com/apache/storm/issues/9073 > https://github.com/apache/storm/issues/9074 > > Kind regards, > > L1nq
