linux-kernel - Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers

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: <20150418125556.GR26185@sirena.org.uk>
Date:	Sat, 18 Apr 2015 13:55:56 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Jonatas Rech <jonatas.rech@...acom.ind.br>
Cc:	linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers

On Wed, Apr 15, 2015 at 12:23:18PM -0300, Jonatas Rech wrote:

> Furthermore, this correction has exposed an inconsistency in the
> protocol driver <-> controller driver interaction. The spi-fsl-espi
> driver artificially inserts TX bytes when message fragmentation is
> necessary (due to SPCOM_TRANLEN_MAX) instead of informing the
> protocol driver of the hardware limitation. This was tested with the
> m25p80 NOR flash protocol driver. Since fixing this issue may cause
> other client drivers to malfunction, it was left as is.

Sorry, you're saying that the driver is sending more data than it's
being asked to in some situations?  That is a *very* serious bug in both
this driver and any other driver which relies on (as opposed to merely
tolerates) this behaviour.  If that is the case it really needs to be
fixed fairly urgently.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)