linux-kernel - Re: [PATCH v3] i2c: exynos5: Init data before registering interrupt handler

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: <4220eff4-4d77-492f-bdcd-a8e44b9c4f81@linaro.org>
Date: Thu, 7 Mar 2024 12:47:46 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Marek Szyprowski <m.szyprowski@...sung.com>,
 Jesper Nilsson <jesper.nilsson@...s.com>, Andi Shyti
 <andi.shyti@...nel.org>, Alim Akhtar <alim.akhtar@...sung.com>
Cc: linux-i2c@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
 kernel@...s.com
Subject: Re: [PATCH v3] i2c: exynos5: Init data before registering interrupt
 handler

On 07/03/2024 12:41, Marek Szyprowski wrote:
> On 05.03.2024 11:50, Jesper Nilsson wrote:
>> devm_request_irq() is called before we initialize the "variant"
>> member variable from of_device_get_match_data(), so if an interrupt
>> is triggered inbetween, we can end up following a NULL pointer
>> in the interrupt handler.
>>
>> This problem was exposed when the I2C controller in question was
>> (mis)configured to be used in both secure world and Linux.
>>
>> That this can happen is also reflected by the existing code that
>> clears any pending interrupts from "u-boot or misc causes".
>>
>> Move the clearing of pending interrupts and the call to
>> devm_request_irq() to the end of probe.
>>
>> Reviewed-by: Andi Shyti <andi.shyti@...nel.org>
>> Fixes: 218e1496135e ("i2c: exynos5: add support for HSI2C on Exynos5260 SoC")
>> Signed-off-by: Jesper Nilsson <jesper.nilsson@...s.com>
>> ---
>> Changes in v3:
>> - Avoid multiple assignment
>> - Link to v2: https://lore.kernel.org/r/20240304-i2c_exynos5-v2-1-7b9c312be719@axis.com
>>
>> Changes in v2:
>> - Use dev_err_probe() instead of open coding it
>> - Dropped the return failure if we can't find a match in devicetree
>> - Link to v1: https://lore.kernel.org/r/20240304-i2c_exynos5-v1-1-e91c889d2025@axis.com
>> ---
>>   drivers/i2c/busses/i2c-exynos5.c | 29 +++++++++++++++--------------
>>   1 file changed, 15 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
>> index 385ef9d9e4d4..8458e22313a7 100644
>> --- a/drivers/i2c/busses/i2c-exynos5.c
>> +++ b/drivers/i2c/busses/i2c-exynos5.c
>> @@ -906,23 +906,9 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
>>   	i2c->adap.algo_data = i2c;
>>   	i2c->adap.dev.parent = &pdev->dev;
>>   
>> -	/* Clear pending interrupts from u-boot or misc causes */
>> -	exynos5_i2c_clr_pend_irq(i2c);
>> -
>>   	spin_lock_init(&i2c->lock);
>>   	init_completion(&i2c->msg_complete);
>>   
>> -	i2c->irq = ret = platform_get_irq(pdev, 0);
>> -	if (ret < 0)
>> -		goto err_clk;
>> -
>> -	ret = devm_request_irq(&pdev->dev, i2c->irq, exynos5_i2c_irq,
>> -			       IRQF_NO_SUSPEND, dev_name(&pdev->dev), i2c);
>> -	if (ret != 0) {
>> -		dev_err(&pdev->dev, "cannot request HS-I2C IRQ %d\n", i2c->irq);
>> -		goto err_clk;
>> -	}
>> -
>>   	i2c->variant = of_device_get_match_data(&pdev->dev);
>>   
>>   	ret = exynos5_hsi2c_clock_setup(i2c);
>> @@ -940,6 +926,21 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
>>   	clk_disable(i2c->clk);
>>   	clk_disable(i2c->pclk);
>>   
>> +	/* Clear pending interrupts from u-boot or misc causes */
>> +	exynos5_i2c_clr_pend_irq(i2c);
> 
> Just above this call the clocks have been disabled, so any access to the 
> i2c host registers will result in freeze or external abort (depending on 
> the soc/cpu).
> 
> To make things worse, this patch moved registering the interrupt handler 
> after the i2c_add_adapter() call. This means that all i2c devices that 
> will be probbed directly from i2c_add_adapter() won't be able to access 
> the i2c bus, as the host controller is still not fully functional that 
> time yet.
> 
> This breaks today's linux-next on all Exynos5+ platforms. Has anyone 
> tested this change?

I don't think so. So that's the reason my boards fail on today's
next/master and next/pending-fixes.

Untested code should not be send as fixes :/

Thanks for reporting Marek (and saving me some bisecting).


Best regards,
Krzysztof