[Bug] Negative frame data length causes IllegalArgumentException in ExchangeCodec

オープン 初心者向け
  • 何か問題がありますか？
#16,447 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@L1nq0 がすでに取り組んでいます。

2026年9月5日 から。

  • #16448 @L1nq0 による — オープン

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
88/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
java
領域
distributed-systems, networking

調査の方向性

dubbo-remoting-api の ExchangeCodec.decode から始め、offset 12 で Bytes.bytes2int を使って読み取られる符号付き長さと、その後の完全性チェックに焦点を当てます。提供されている 16 バイトの負の長さのフレーム、または codec の直接的な再現を使用し、その後、ストリームコンストラクターから IllegalArgumentException が外部に漏れずに無効なフレームが拒否されることを示す回帰テストを追加します。

索引モデルが issue の本文から書いたものです。

説明

component/need-triage type/need-triage
Pre-check
  • I am sure that all the content I provide is in English.
Search before asking
  • I had searched in the issues and found no similar issues.
Apache Dubbo Component

Java SDK (apache/dubbo)

Dubbo Version

Dubbo Java 3.3.6 (tag dubbo-3.3.6); the same code is unchanged on the 3.3 branch (checked today).
OpenJDK 21, Linux.
Protocol: dubbo.

Steps to reproduce this issue

While testing how the dubbo protocol codec handles invalid frames locally, we found that a frame whose header declares a negative data length makes decode throw IllegalArgumentException before decodeBody is reached.

A complete minimal frame is 16 bytes:

da bb c2 00 ff ff ff ff ff ff ff ff ff ff ff ff

magic dabb, flag c2 (request, twoway, hessian2), requestId all ff, and the data length field at offset 12 set to ffffffff, which reads back as -1.

Passing these bytes to DubboCodec.decode, or writing them to a provider port over TCP, throws:

java.lang.IllegalArgumentException: length: -1
    at org.apache.dubbo.remoting.buffer.ChannelBufferInputStream.<init>(ChannelBufferInputStream.java:37)
    at org.apache.dubbo.remoting.exchange.codec.ExchangeCodec.decode(ExchangeCodec.java:134)
    at org.apache.dubbo.remoting.exchange.codec.ExchangeCodec.decode(ExchangeCodec.java:92)

On the netty4 transport the exception leaves the codec and is handled as a connection-level exception (logged, connection closed).

What you expected to happen

A header declaring a negative data length is not a valid frame, and no additional input can make it one. decode should reject such a frame as invalid at the point the length is read, instead of letting a stream constructor throw an uncaught IllegalArgumentException from inside the codec. A sign check on len right after Bytes.bytes2int would cover it; returning NEED_MORE_INPUT would not fit here, since it would leave the channel waiting for input that can never make a negative length valid.

Anything else

Root cause, in ExchangeCodec (dubbo-remoting-api, tag dubbo-3.3.6):

  • line 119: the data length is read as a signed int (Bytes.bytes2int(header, 12))
  • line 123: finishRespWhenOverPayload only compares against the payload upper bound, and only for responses
  • line 129: the completeness check (readable < len + 16) passes for every negative len
  • line 134: ChannelBufferInputStream rejects negative lengths with IllegalArgumentException, which escapes decode

We have the 16-byte reproducer and a direct codec call available as a minimal demo, and are willing to submit a PR with the check and a test.

Do you have a (mini) reproduction demo?
  • Yes, I have a minimal reproduction demo to help resolve this issue more effectively!
Are you willing to submit a pull request to fix on your own?
  • Yes I am willing to submit a pull request on my own!
Code of Conduct
主要言語
Java
スター
41.6k
フォーク
26.3k
平均マージ
1日 22時間
マージ済み PR（30日）
19

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/dubbo のほかの issue

apache/dubbo の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。