From: "Christian König" <christian.koenig@amd.com>
To: "Lazar, Lijo" <lijo.lazar@amd.com>,
Dmitriy Chumachenko <Dmitry.Chumachenko@cyberprotect.ru>,
Alexander Deucher <alexander.deucher@amd.com>
Cc: David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Hawking Zhang <Hawking.Zhang@amd.com>,
Samuel Zhang <guoqing.zhang@amd.com>,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, lvc-project@linuxtesting.org
Subject: Re: [PATCH] drm/amdgpu: zero reg_state buffer before filling it
Date: Mon, 14 Sep 2026 19:48:41 +0200 [thread overview]
Message-ID: <41428e7e-22e3-44d5-afdf-8a72165883f5@amd.com> (raw)
In-Reply-To: <c4f2f082-8956-4f20-af92-119b873c3759@amd.com>
On 9/14/26 17:25, Lazar, Lijo wrote:
> On 14-Sep-26 8:24 PM, Christian König wrote:
>> On 9/14/26 16:45, Lazar, Lijo wrote:
>>>
>>>
>>> On 14-Sep-26 7:30 PM, Christian König wrote:
>>>> On 9/14/26 15:56, Dmitriy Chumachenko wrote:
>>>>> The reg_state readouts return szbuf bytes but never write the pad members
>>>>> of the headers and of amdgpu_smn_reg_data (and, for pcie, the fields
>>>>> skipped when the upstream port or AER capability is absent). The sysfs
>>>>> buffer is a plain kmalloc(), so those bytes leak stale slab data to any
>>>>> local user through the 0444 reg_state attribute.
>>>>>
>>>>> Zero the buffer once the size is known.
>>>>>
>>>>> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>>>>>
>>>>> Fixes: 081a6eda2b25 ("drm/amdgpu: Read aquavanjaram PCIE register state")
>>>>> Signed-off-by: Dmitriy Chumachenko <Dmitry.Chumachenko@cyberprotect.ru>
>>>>
>>>> Good catch, but stuff like that should be handled by using kzalloc() instead of calling memset it manually.
>>>>
>>>
>>> It's the default sysfs buffer allocation which may not be used entirely by all drivers.
>>>
>>> The concern in this case is that driver is telling it has written x bytes whereas it could have left some fields unfilled in the buffer. I think the fix is fine.
>>
>> Wait a second, is that because of messed up padding in sysfs structures? That is usually a really big NO-GO for upstreaming.
>>
>> Structures returned to userspace must be padding free, see the tool pahole for how to double check that on different architectures.
>>
>
> It's an explicit padding like below for alignment. Those fields also could go unfilled.
>
> struct amdgpu_reg_state_header {
> uint16_t structure_size;
> uint8_t format_revision;
> uint8_t content_revision;
> uint8_t state_type;
> uint8_t num_instances;
> uint16_t pad;
> };
Ok, got it. Yeah that approach is perfectly fine.
But we should still us kzalloc() or at least do the memset at the IOCTL level and not in the backend.
Regards,
Christian.
>
> Thanks,
> Lijo
>
>> Regards,
>> Christian.
>>
>>>
>>> Thanks,
>>> Lijo
>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>> ---
>>>>> drivers/gpu/drm/amd/amdgpu/aqua_vanjaram.c | 8 ++++++++
>>>>> 1 file changed, 8 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/aqua_vanjaram.c b/drivers/gpu/drm/amd/amdgpu/aqua_vanjaram.c
>>>>> index 72ea37dbfea8..0086de0f685d 100644
>>>>> --- a/drivers/gpu/drm/amd/amdgpu/aqua_vanjaram.c
>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/aqua_vanjaram.c
>>>>> @@ -610,6 +610,8 @@ static ssize_t aqua_vanjaram_read_pcie_state(struct amdgpu_device *adev,
>>>>> if (max_size < szbuf)
>>>>> return -EOVERFLOW;
>>>>>
>>>>> + memset(buf, 0, szbuf);
>>>>> +
>>>>> pcie_regs = (struct amdgpu_regs_pcie_v1_0 *)((uint8_t *)buf +
>>>>> sizeof(*pcie_reg_state));
>>>>> pcie_regs->inst_header.instance = 0;
>>>>> @@ -702,6 +704,8 @@ static ssize_t aqua_vanjaram_read_xgmi_state(struct amdgpu_device *adev,
>>>>> if (max_size < szbuf)
>>>>> return -EOVERFLOW;
>>>>>
>>>>> + memset(buf, 0, szbuf);
>>>>> +
>>>>> p = &xgmi_reg_state->xgmi_state_regs[0];
>>>>> for_each_inst(i, adev->aid_mask) {
>>>>> for (j = 0; j < xgmi_inst; ++j) {
>>>>> @@ -776,6 +780,8 @@ static ssize_t aqua_vanjaram_read_wafl_state(struct amdgpu_device *adev,
>>>>> if (max_size < szbuf)
>>>>> return -EOVERFLOW;
>>>>>
>>>>> + memset(buf, 0, szbuf);
>>>>> +
>>>>> p = &wafl_reg_state->wafl_state_regs[0];
>>>>> for_each_inst(i, adev->aid_mask) {
>>>>> for (j = 0; j < wafl_inst; ++j) {
>>>>> @@ -902,6 +908,8 @@ static ssize_t aqua_vanjaram_read_usr_state(struct amdgpu_device *adev,
>>>>> if (max_size < szbuf)
>>>>> return -EOVERFLOW;
>>>>>
>>>>> + memset(buf, 0, szbuf);
>>>>> +
>>>>> p = &usr_reg_state->usr_state_regs[0];
>>>>> for_each_inst(i, adev->aid_mask) {
>>>>> usr_regs = (struct amdgpu_regs_usr_v1_0 *)p;
>>>>> --
>>>>> 2.49.0
>>>>>
>>>>
>>>
>>
>
next prev parent reply other threads:[~2026-09-14 17:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 13:56 Dmitriy Chumachenko
2026-09-14 14:00 ` Christian König
2026-09-14 14:45 ` Lazar, Lijo
2026-09-14 14:54 ` Christian König
2026-09-14 15:25 ` Lazar, Lijo
2026-09-14 17:48 ` Christian König [this message]
2026-09-14 14:46 ` Lazar, Lijo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41428e7e-22e3-44d5-afdf-8a72165883f5@amd.com \
--to=christian.koenig@amd.com \
--cc=Dmitry.Chumachenko@cyberprotect.ru \
--cc=Hawking.Zhang@amd.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=guoqing.zhang@amd.com \
--cc=lijo.lazar@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=simona@ffwll.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®