I believe the fix for CVE-2026-44248 (see here) has a problem that breaks MQTT decoding.
I noticed this after I upgraded Apache Artemis from 4.1.132.Final to 4.1.133.Final and some of our MQTT integration tests started failing.
The problem appears to be that when the Signal is thrown the comparison uses initialAvailableBytes < maxBytesInMessage. Here initialAvailableBytes is the total number of bytes in the buffer (i.e. buffer.readableBytes()). However, there can be multiple MQTT packets in the buffer in which case decoding will bail-out illegitimately. I believe the comparison should rather be bytesRemainingBeforeVariableHeader < maxBytesInMessage.
Unfortunately I haven't been able to put together a unit test in Netty to demonstrate this problem yet, but I wanted to report it in case someone else with expertise might be able to investigate further.
I believe the fix for CVE-2026-44248 (see here) has a problem that breaks MQTT decoding.
I noticed this after I upgraded Apache Artemis from 4.1.132.Final to 4.1.133.Final and some of our MQTT integration tests started failing.
The problem appears to be that when the
Signalis thrown the comparison usesinitialAvailableBytes < maxBytesInMessage. HereinitialAvailableBytesis the total number of bytes in the buffer (i.e.buffer.readableBytes()). However, there can be multiple MQTT packets in the buffer in which case decoding will bail-out illegitimately. I believe the comparison should rather bebytesRemainingBeforeVariableHeader < maxBytesInMessage.Unfortunately I haven't been able to put together a unit test in Netty to demonstrate this problem yet, but I wanted to report it in case someone else with expertise might be able to investigate further.