bhuvan-somisetty opened a new pull request, #13953:
URL: https://github.com/apache/apisix/pull/13953

   ### Description
   
   `decode_variable_byte_int()` in the `mqtt-proxy` stream plugin reads up to 4 
bytes to decode an MQTT variable-byte-integer, but it never checked that the 
index it was reading stayed inside the buffer it was given. It's used to decode 
the MQTT v5 "Properties Length" field, and unlike the client-ID length handling 
a few lines below it (which correctly checks `parsed_pos + client_id_len > 
#data` before reading), there was no equivalent guard here.
   
   If the properties-length bytes have the continuation bit (0x80) set all the 
way to the end of the peeked buffer, `string.byte()` returns nothing for the 
out-of-range index, `byte` ends up `nil`, and `bit.band(nil, 127)` raises an 
uncaught Lua error. That happens inside the `preread` phase, so instead of 
getting the plugin's normal `core.log.error(...); return 503` handling that 
every other malformed-packet case in this file gets, the connection just errors 
out.
   
   This PR adds the missing bounds check in `decode_variable_byte_int`, and 
propagates the failure up through `parse_mqtt`/`parse_msg_hdr` so `preread()` 
now rejects a malformed/truncated properties length with a clean 503, same as 
it already does for a bad packet type or a truncated client ID.
   
   #### Which issue(s) this PR fixes:
   
   Fixes #13952
   
   ### Checklist
   
   - [x] I have explained the need for this PR and the problem it solves
   - [x] I have explained the changes or the new features added to this PR
   - [x] I have added tests corresponding to this change
   - [ ] I have updated the documentation to reflect this change
   - [x] I have verified that this change is backward compatible
   


-- 
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]

Reply via email to