chaokunyang commented on code in PR #3429:
URL: https://github.com/apache/fory/pull/3429#discussion_r2867137076
##########
python/pyfory/buffer.pyx:
##########
@@ -283,8 +283,10 @@ cdef class Buffer:
if length > 0:
self.c_buffer.write_bytes(&data[0], length)
- cpdef inline bytes read_bytes_and_size(self):
+ cpdef inline bytes read_bytes_and_size(self, int32_t max_binary_size=-1):
Review Comment:
THis methdo doesn't hae preallocation, we don't need to check size
##########
python/pyfory/buffer.pyx:
##########
@@ -283,8 +283,10 @@ cdef class Buffer:
if length > 0:
self.c_buffer.write_bytes(&data[0], length)
- cpdef inline bytes read_bytes_and_size(self):
+ cpdef inline bytes read_bytes_and_size(self, int32_t max_binary_size=-1):
Review Comment:
[P1] New optional max parameter leaves most binary-length reads unguarded
`read_bytes_and_size` now accepts `max_binary_size`, but defaulting to `-1`
means existing call sites still bypass guardrails unless explicitly updated. In
this PR only `BytesSerializer.read` passes the limit; other binary payload
readers (e.g. array/numpy serializers and marshal code reads in
`serializer.py`) still call `read_bytes_and_size()` without a limit, so
untrusted payloads can trigger large allocations through those paths.
Repro example: `array.array` deserialization with `Fory(max_binary_size=10)`
still accepts payloads much larger than 10 bytes.
--
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]
