All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Larsson <benjamin@southpole.se>
To: linux-media@vger.kernel.org, Antti Palosaari <crope@iki.fi>
Subject: Re: Random memory corruption of fe[1]->dvb pointer
Date: Tue, 02 Dec 2014 00:30:04 +0100	[thread overview]
Message-ID: <547CF9FC.5010101@southpole.se> (raw)
In-Reply-To: <547BAC79.50702@southpole.se>

I think I have found the issue for this error and it looks like a use 
after free that affects multiple drivers. The effect is that the driver 
crashes on unload.

I added the following code to the mn88472 driver, it should behave as a nop:

diff --git a/drivers/staging/media/mn88472/mn88472.c 
b/drivers/staging/media/mn88472/mn88472.c
index 52de8f8..58af319 100644
--- a/drivers/staging/media/mn88472/mn88472.c
+++ b/drivers/staging/media/mn88472/mn88472.c
@@ -494,6 +494,7 @@ static int mn88472_remove(struct i2c_client *client)

         regmap_exit(dev->regmap[0]);

+       memset(dev, 0, sizeof(*dev));
         kfree(dev);


When I now unload the driver I get the following code flow:

usb 1-1: rtl28xxu_exit:
mn88472 2-0018: mn88472_remove:  <-- this call will actually free the 
fe[1] pointer, I added the memset to make sure they where null
usb 1-1: dvb_usbv2_exit:
usb 1-1: dvb_usbv2_remote_exit:
usb 1-1: dvb_usbv2_adapter_exit:
usb 1-1: dvb_usbv2_adapter_exit: fe0[0]=0xffff88007a8b0018
usb 1-1: dvb_usbv2_adapter_exit: fe0[0]->dvb=0xffff88007a142580
usb 1-1: dvb_usbv2_adapter_exit: fe0[0]->demodulator_priv=0xffff88007a8b0000
usb 1-1: dvb_usbv2_adapter_exit: fe1[0]=0xffff88007a8d0030
usb 1-1: dvb_usbv2_adapter_exit: fe1[0]->dvb=0x          (null)
usb 1-1: dvb_usbv2_adapter_exit: fe1[0]->demodulator_priv=0x          (null)
BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
IP: [<ffffffffa021f3de>] dvb_unregister_frontend+0x2a/0xf1 [dvb_core]

dvb_unregister_frontend() is sent the fe[1] pointer which now is null 
and thus crashes with a null pointer dereference. A use after free issue.

I looked for similar code and found it in:
si2168.c
af9033.c
tc90522.c

sp2.c has the same structure but I think it is fine.

So at first it would be nice if someone could confirm my findings. 
Applying the same kind of code like my patch and unplug something that 
uses the affected frontend should be enough.

MvH
Benjamin Larsson

  reply	other threads:[~2014-12-01 23:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-30 23:47 Random memory corruption of fe[1]->dvb pointer Benjamin Larsson
2014-12-01 23:30 ` Benjamin Larsson [this message]
2014-12-02  9:47   ` Akihiro TSUKADA
2014-12-02 10:02     ` Antti Palosaari
2014-12-02 10:41       ` Benjamin Larsson
2014-12-02 10:59         ` Antti Palosaari
2014-12-02 11:52           ` Benjamin Larsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=547CF9FC.5010101@southpole.se \
    --to=benjamin@southpole.se \
    --cc=crope@iki.fi \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.