linux-kernel - Re: [PATCH] eeprom: at25: convert to spi-mem API

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: <a74bac93-88de-4d45-9961-b5a3aa342c70@csgroup.eu>
Date: Tue, 4 Nov 2025 14:24:17 +0100
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc: "hui.wang@...onical.com" <hui.wang@...onical.com>,
 "mwalle@...nel.org" <mwalle@...nel.org>,
 "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
 "florent.trinh-thai@...soprasteria.com"
 <florent.trinh-thai@...soprasteria.com>, "arnd@...db.de" <arnd@...db.de>
Subject: Re: [PATCH] eeprom: at25: convert to spi-mem API

Hi Alexander,

Le 04/11/2025 à 14:13, Sverdlin, Alexander a écrit :
> Hi Christophe,
> 
> On Mon, 2025-11-03 at 23:36 +0100, Christophe Leroy wrote:
>>>>>>> Replace the RAW SPI accesses with spi-mem API. The latter will fall back to
>>>>>>> RAW SPI accesses if spi-mem callbacks are not implemented by a controller
>>>>>>> driver.
>>>>>>
>>>>>> With this patch (kernel v6.17.1) our powerpc boards are totally
>>>>>> unstable, we get multiple random Oops due to bad memory accesses.
>>>>>>
>>>>>> With this commit reverted the board is stable again.
>>>>>>
>>>>>> The SPI driver is:
>>>>>>
>>>>>> CONFIG_SPI=y
>>>>>> CONFIG_SPI_MASTER=y
>>>>>> CONFIG_SPI_MEM=y
>>>>>> CONFIG_SPI_FSL_LIB=y
>>>>>> CONFIG_SPI_FSL_CPM=y
>>>>>> CONFIG_SPI_FSL_SPI=y
>>>>>>
>>>>>> How can we further investigate the issue ?
>>>>>
>>>>> could you share these "random Oops"?
>>>>
>>>> Sure. At the first place they look unrelated. Something is likely
>>>
>>> indeed, no obvious connection... Do you have a chance to run KASAN?
>>
>> I ran KASAN, it found an overrun in the loop in
>> fsl_spi_cpm_bufs_complete() when t->len is odd, but once fixed the
>> random problem is still there.
> 
> thanks for the quick reply!
> That sounds promising already!
> 
> Do you have a chance to run with CONFIG_DEBUG_STACKOVERFLOW=y ?
> 

Unfortunately I won't be able to do any additionnal test until Monday 
next week as I'm travelling at the moment.

However, our kernel is built with CONFIG_VMAP_STACK, so a stack overflow 
would have been caught by the early stack overflow detection, see commit 
3978eb78517c ("powerpc/32: Add early stack overflow detection with VMAP 
stack.") for details.

Christophe