linux-kernel - Re: [PATCH 4.19 21/38] spi: fsl-espi: Only process interrupts for expected events

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: <e96519d3-8b58-4715-1ada-6139749e6da3@alliedtelesis.co.nz>
Date:   Sun, 11 Oct 2020 19:47:26 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     Pavel Machek <pavel@...x.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Mark Brown <broonie@...nel.org>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 21/38] spi: fsl-espi: Only process interrupts for
 expected events


On 7/10/20 8:36 am, Pavel Machek wrote:
> Hi!
>
>> [ Upstream commit b867eef4cf548cd9541225aadcdcee644669b9e1 ]
>>
>> The SPIE register contains counts for the TX FIFO so any time the irq
>> handler was invoked we would attempt to process the RX/TX fifos. Use the
>> SPIM value to mask the events so that we only process interrupts that
>> were expected.
>>
>> This was a latent issue exposed by commit 3282a3da25bd ("powerpc/64:
>> Implement soft interrupt replay in C").
> We don't seem to have commit 3282... in 4.19, so we don't need this
> one in 4.19-stable according to the changelog.
Technically 3282... exposed the issue by making it more likely to happen 
so 4.19 might just have a really low probability of seeing the issue (I 
think I did try reproducing it on kernels of that vintage). Personally 
I'm not too fussed the kernel versions I care about have the fix. Maybe 
someone from NXP cares enough to pursue it.