* [PATCH] spi: core: Fix Oops in spi_pump_messages error path
@ 2014-02-17 17:20 Maxime Ripard
2014-02-17 18:02 ` Geert Uytterhoeven
0 siblings, 1 reply; 3+ messages in thread
From: Maxime Ripard @ 2014-02-17 17:20 UTC (permalink / raw)
To: Mark Brown
Cc: linux-spi, linux-kernel, kevin.z.m.zh, sunny, shuge, zhuzhenhua,
Maxime Ripard, stable
When the generic implementation of the transfer_one_message callback was called
by the spi_pump_messages function, if that transfer was to fail, the
spi_finalize_current_message was called twice, once in
spi_transfer_one_message, and one in spi_pump_messages.
This was causing a null pointer dereference in the second call, because the
first one set the ->cur_msg field to NULL.
Since the SPI framework expect the transfer_one_message callback to call
spi_finalize_current_message, we can remove it from spi_pump_messages, together
with any dereference of the ->cur_msg pointer.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: stable@vger.kernel.org
---
drivers/spi/spi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 23756b0..39f12be 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -756,8 +756,6 @@ static void spi_pump_messages(struct kthread_work *work)
if (ret) {
dev_err(&master->dev,
"failed to transfer one message from queue: %d\n", ret);
- master->cur_msg->status = ret;
- spi_finalize_current_message(master);
return;
}
}
--
1.8.4.2
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] spi: core: Fix Oops in spi_pump_messages error path
2014-02-17 17:20 [PATCH] spi: core: Fix Oops in spi_pump_messages error path Maxime Ripard
@ 2014-02-17 18:02 ` Geert Uytterhoeven
[not found] ` <CAMuHMdXc5zyd1aBigrisvx43VVjStCMgtCcHmefdK-n5shTTmA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 3+ messages in thread
From: Geert Uytterhoeven @ 2014-02-17 18:02 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Brown, linux-spi, linux-kernel@vger.kernel.org, kevin.z.m.zh,
sunny, shuge, zhuzhenhua, stable
On Mon, Feb 17, 2014 at 6:20 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> When the generic implementation of the transfer_one_message callback was called
> by the spi_pump_messages function, if that transfer was to fail, the
> spi_finalize_current_message was called twice, once in
> spi_transfer_one_message, and one in spi_pump_messages.
>
> This was causing a null pointer dereference in the second call, because the
> first one set the ->cur_msg field to NULL.
>
> Since the SPI framework expect the transfer_one_message callback to call
> spi_finalize_current_message, we can remove it from spi_pump_messages, together
> with any dereference of the ->cur_msg pointer.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Cc: stable@vger.kernel.org
Already fixed in v3.14-rc3 in 1f802f8249a0da536877842c43c7204064c4de8b
("spi: Fix crash with double message finalisation on error handling").
There's no need to inform stable, as the problem was introduced in v3.14-rc1.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] spi: core: Fix Oops in spi_pump_messages error path
[not found] ` <CAMuHMdXc5zyd1aBigrisvx43VVjStCMgtCcHmefdK-n5shTTmA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2014-02-18 7:37 ` Maxime Ripard
0 siblings, 0 replies; 3+ messages in thread
From: Maxime Ripard @ 2014-02-18 7:37 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Brown, linux-spi,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kevin.z.m.zh-Re5JQEeQqe8AvxtiuMwx3w,
sunny-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
shuge-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
zhuzhenhua-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf, stable
[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]
Hi Geert,
On Mon, Feb 17, 2014 at 07:02:09PM +0100, Geert Uytterhoeven wrote:
> On Mon, Feb 17, 2014 at 6:20 PM, Maxime Ripard
> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > When the generic implementation of the transfer_one_message callback was called
> > by the spi_pump_messages function, if that transfer was to fail, the
> > spi_finalize_current_message was called twice, once in
> > spi_transfer_one_message, and one in spi_pump_messages.
> >
> > This was causing a null pointer dereference in the second call, because the
> > first one set the ->cur_msg field to NULL.
> >
> > Since the SPI framework expect the transfer_one_message callback to call
> > spi_finalize_current_message, we can remove it from spi_pump_messages, together
> > with any dereference of the ->cur_msg pointer.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>
> Already fixed in v3.14-rc3 in 1f802f8249a0da536877842c43c7204064c4de8b
> ("spi: Fix crash with double message finalisation on error handling").
>
> There's no need to inform stable, as the problem was introduced in v3.14-rc1.
Oops, totally missed that. Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-02-18 7:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-17 17:20 [PATCH] spi: core: Fix Oops in spi_pump_messages error path Maxime Ripard
2014-02-17 18:02 ` Geert Uytterhoeven
[not found] ` <CAMuHMdXc5zyd1aBigrisvx43VVjStCMgtCcHmefdK-n5shTTmA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-02-18 7:37 ` Maxime Ripard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).