Hi, On 11/7/22 19:54, David E. Box wrote: > On Wed, 2022-11-02 at 22:23 +0100, Armin Wolf wrote: >> When the DDV interface returns a buffer, it actually >> returns a acpi buffer containing an integer (buffer size) >> and another acpi buffer (buffer content). >> The size of the buffer may be smaller than the size of >> the buffer content, which is perfectly valid and should not >> be treated as an error. > > Is there documentation for this that you can refer to? > >> Also use the buffer size instead of the buffer content size >> when accessing the buffer to prevent accessing bogus data. >> >> Tested on a Dell Inspiron 3505. >> >> Signed-off-by: Armin Wolf <W_Armin@xxxxxx> >> --- >> drivers/platform/x86/dell/dell-wmi-ddv.c | 12 +++++++----- >> 1 file changed, 7 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/platform/x86/dell/dell-wmi-ddv.c >> b/drivers/platform/x86/dell/dell-wmi-ddv.c >> index 699feae3c435..1a001296e8c6 100644 >> --- a/drivers/platform/x86/dell/dell-wmi-ddv.c >> +++ b/drivers/platform/x86/dell/dell-wmi-ddv.c >> @@ -129,9 +129,9 @@ static int dell_wmi_ddv_query_buffer(struct wmi_device >> *wdev, enum dell_ddv_meth >> if (obj->package.elements[1].type != ACPI_TYPE_BUFFER) >> goto err_free; >> >> - if (buffer_size != obj->package.elements[1].buffer.length) { >> + if (buffer_size > obj->package.elements[1].buffer.length) { >> dev_warn(&wdev->dev, >> - FW_WARN "ACPI buffer size (%llu) does not match WMI >> buffer size (%d)\n", >> + FW_WARN "WMI buffer size (%llu) exceeds ACPI buffer >> size (%d)\n", >> buffer_size, obj->package.elements[1].buffer.length); >> >> goto err_free; >> @@ -271,15 +271,17 @@ static int dell_wmi_ddv_buffer_read(struct seq_file >> *seq, enum dell_ddv_method m >> struct device *dev = seq->private; >> struct dell_wmi_ddv_data *data = dev_get_drvdata(dev); >> union acpi_object *obj; >> - union acpi_object buf; >> + u64 size; >> + u8 *buf; >> int ret; >> >> ret = dell_wmi_ddv_query_buffer(data->wdev, method, 0, &obj); >> if (ret < 0) >> return ret; >> >> - buf = obj->package.elements[1]; >> - ret = seq_write(seq, buf.buffer.pointer, buf.buffer.length); >> + size = obj->package.elements[0].integer.value; >> + buf = obj->package.elements[1].buffer.pointer; >> + ret = seq_write(seq, buf, size); > > Okay, so the buffer may provide more space than what should actually be used > according to the size field. This looks like a bug that should have a fixes tag > on the original commit. I have already merged this and both the original commit as well as this fix will land in 6.2, so I don't think a Fixes commit is really necessary in this case. Also the old code checked that the 2 sizes matched, so it was more strict and as such running only the original patch should not lead to buffer overruns or anything like that. Regards, Hans