Am 24.05.24 um 00:49 schrieb Jeremy Allison via samba-technical:
On Thu, May 23, 2024 at 12:28:35PM -0300, Paulo Alcantara wrote:
Tom Talpey <tom@xxxxxxxxxx> writes:
Yeah, I think this is a Samba server issue. Ronnie is right that it
should return a partial response and a STATUS_BUFFER_OVERFLOW error
indicating that it's partial. It's not supposed to return
STATUS_BUFFER_TOO_SMALL unless the entire buffer is less than one
entry.
MS-FSA section 2.5.10.22
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fsa/385dec98-90fe-477f-9789-20a47a7b8467
Yes. I've just tested it against Windows Server 2022 and it correctly
returns STATUS_BUFFER_OVERFLOW.
Bug is in fsctl_qar():
ndr_ret = ndr_push_struct_blob(out_output, mem_ctx, &qar_rsp,
(ndr_push_flags_fn_t)ndr_push_fsctl_query_alloced_ranges_rsp);
if (ndr_ret != NDR_ERR_SUCCESS) {
DEBUG(0, ("failed to marshall QAR rsp\n"));
return NT_STATUS_INVALID_PARAMETER;
}
if (out_output->length > in_max_output) {
DEBUG(2, ("QAR output len %lu exceeds max %lu\n",
(unsigned long)out_output->length,
(unsigned long)in_max_output));
data_blob_free(out_output);
return NT_STATUS_BUFFER_TOO_SMALL;
}
I'm guessing in this case we need to just truncate out_output->length
to in_max_output and return STATUS_BUFFER_OVERFLOW.
But I guess we should only truncate at multiples of the size of a single entry.
and return BUFFER_TOO_SMALL when it's to small to hold a single entry.
As far as I can see struct file_alloced_range_buf has a size of 16.
I guess fsctl_qar_buf_push() should also get a max_output_length argument
and should check early if additional 16 bytes can be appended
and return NT_STATUS_BUFFER_TOO_SMALL if not.
Then fsctl_qar_seek_fill() should catch NT_STATUS_BUFFER_TOO_SMALL and turn it
into STATUS_BUFFER_OVERFLOW if at least one element was filled in before.
metze
