Aias00 opened a new issue, #3524:
URL: https://github.com/apache/dubbo-go/issues/3524

   ### Problem
   
   `unpackRequestBody` decodes the Dubbo Hessian2 request body field by field. 
The 5th field (`argsTypes`, the argument-types descriptor, e.g. 
`"Ljava/lang/String;"`) is decoded and then used in an **unchecked** type 
assertion:
   
   ```go
   // protocol/dubbo/hessian2/hessian_request.go:226-232
   argsTypes, err = decoder.Decode()
   if err != nil {
       return perrors.WithStack(err)
   }
   req[4] = argsTypes
   
   ats := DescRegex.FindAllString(argsTypes.(string), -1)   // unchecked 
assertion
   ```
   
   `decoder.Decode()` can return `(nil, nil)` (a Hessian null marker decodes to 
nil with no error) or any non-string value for a malformed/hostile request. 
`argsTypes.(string)` then panics, crashing the server-side goroutine handling 
the request (the Dubbo protocol listener), dropping the connection.
   
   ### Current behavior
   
   1. A Dubbo Hessian2 request whose argument-types field is Hessian `null` (or 
any non-string) is decoded to `(nil, nil)`.
   2. `argsTypes.(string)` panics.
   3. The server goroutine handling that request crashes (connection drop / 
`recover`).
   
   ### Expected behavior
   
   A malformed argument-types descriptor should return a clear protocol error 
instead of panicking; an empty string (zero args) must keep working.
   
   ### Suggested approach
   
   - Use a comma-ok type assertion: `argsTypesStr, ok := argsTypes.(string); if 
!ok { return error }`.
   - `DescRegex.FindAllString(argsTypesStr, -1)` on the validated string.
   
   ### Acceptance criteria
   
   - [ ] A request whose argsTypes field is Hessian null no longer panics; 
`unpackRequestBody` returns a descriptive error.
   - [ ] A request with an empty-string argsTypes (zero args) still decodes 
successfully.
   - [ ] Existing `TestPackRequest` / request-decoding tests remain green.
   - [ ] Regression test covers the null-argsTypes path.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to