linux-kernel - Re: [PATCH] memory: mtk-smi: Fix a null dereference for the ostd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <82835e3d-11a3-32e4-0782-d827a5e3d78e@canonical.com>
Date:   Mon, 1 Nov 2021 09:45:38 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     Yong Wu <yong.wu@...iatek.com>
Cc:     Krzysztof Kozlowski <krzk@...nel.org>,
        Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
        Robin Murphy <robin.murphy@....com>,
        Tomasz Figa <tfiga@...omium.org>,
        linux-mediatek@...ts.infradead.org, srv_heupstream@...iatek.com,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        iommu@...ts.linux-foundation.org, youlin.pei@...iatek.com,
        anan.sun@...iatek.com, yi.kuo@...iatek.com,
        anthony.huang@...iatek.com, Ikjoon Jang <ikjn@...omium.org>,
        Matthias Brugger <matthias.bgg@...il.com>
Subject: Re: [PATCH] memory: mtk-smi: Fix a null dereference for the ostd

On 01/11/2021 07:09, Yong Wu wrote:
> On Fri, 2021-10-29 at 19:35 +0200, Krzysztof Kozlowski wrote:
>> On 28/10/2021 07:50, Yong Wu wrote:
>>> We add the ostd setting for mt8195. It introduces a abort for the
>>> previous SoC which doesn't have ostd setting. This is the log:
>>>
>>> Unable to handle kernel NULL pointer dereference at virtual address
>>> 0000000000000080
>>> ...
>>> pc : mtk_smi_larb_config_port_gen2_general+0x64/0x130
>>> lr : mtk_smi_larb_resume+0x54/0x98
>>> ...
>>> Call trace:
>>>  mtk_smi_larb_config_port_gen2_general+0x64/0x130
>>>  pm_generic_runtime_resume+0x2c/0x48
>>>  __genpd_runtime_resume+0x30/0xa8
>>>  genpd_runtime_resume+0x94/0x2c8
>>>  __rpm_callback+0x44/0x150
>>>  rpm_callback+0x6c/0x78
>>>  rpm_resume+0x310/0x558
>>>  __pm_runtime_resume+0x3c/0x88
>>>
>>> In the code: larbostd = larb->larb_gen->ostd[larb->larbid],
>>> if "larb->larb_gen->ostd" is null, the "larbostd" is the offset, it
>>> is
>>> also a valid value, thus, use the larb->larb_gen->ostd as the
>>> condition
>>> inside the "for" loop.
>>
>> You need to write more clearly, what you are fixing here.
>>
>>>
>>> Signed-off-by: Yong Wu <yong.wu@...iatek.com>
>>> ---
>>> Hi Krzysztof,
>>> Could you help review and conside this as a fix for the mt8195
>>> patchset?
>>> The mt8195 patchset are not in mainline, thus, I don't know its
>>> sha-id,
>>> and don't add Fixes tag.
>>> Thanks
>>> ---
>>>  drivers/memory/mtk-smi.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
>>> index b883dcc0bbfa..0262a59a2d6e 100644
>>> --- a/drivers/memory/mtk-smi.c
>>> +++ b/drivers/memory/mtk-smi.c
>>> @@ -257,7 +257,7 @@ static void
>>> mtk_smi_larb_config_port_gen2_general(struct device *dev)
>>>  	if (MTK_SMI_CAPS(flags_general, MTK_SMI_FLAG_SW_FLAG))
>>>  		writel_relaxed(SMI_LARB_SW_FLAG_1, larb->base +
>>> SMI_LARB_SW_FLAG);
>>>  
>>> -	for (i = 0; i < SMI_LARB_PORT_NR_MAX && larbostd &&
>>> !!larbostd[i]; i++)
>>> +	for (i = 0; i < SMI_LARB_PORT_NR_MAX && larb->larb_gen->ostd &&
>>> !!larbostd[i]; i++)
>>>  		writel_relaxed(larbostd[i], larb->base +
>>> SMI_LARB_OSTDL_PORTx(i));
>>
>> The code does not look good. You have already a dereference at line
>> 244:
>>
>> 	const u8 *larbostd = larb->larb_gen->ostd[larb->larbid];
> 
> if larb->larb_gen->ostd is null, larbostd is the offset, e.g. 0x80 in
> the log above. thus, we can not use "larbostd[i]" in the "for" loop.
> 
> sorry for the unreadable. In this case, is the change ok?

No, it's ok, I did not check the type of ostd and it's confusing a bit
that it is defined as a pointer to an array but you actually use it as
array of pointers to 32-elemenet arrays... Anyway I was mistaken and
there will be indeed no dereference at the assignment, but for code
clarity I would still prefer to do the check earlier, so:

> 
> or like this:
> 
> -const u8 *larbostd = larb->larb_gen->ostd[larb->larbid];
> +const u8 *larbostd = larb->larb_gen->ostd ? larb->larb_gen-ostd[larb-
>> larbid] : NULL;

Although I think now the proper type should be explicit.
mtk_smi_larb_mt8195_ostd is an 28-element array of
SMI_LARB_PORT_NR_MAX-element u8 arrays, therefore struct
mtk_smi_larb_gen should be:
	const u8 (*ostd)[][SMI_LARB_PORT_NR_MAX];

Right?


Best regards,
Krzysztof