LKML Archive on
help / color / mirror / Atom feed
From: Thorsten Bschorr <>
Cc: Evgeniy Polyakov <>, David Fries <>
Subject: Fwd: w1/slaves/w1_therm: null-ptr access of sl->family_data
Date: Mon, 23 Feb 2015 18:09:16 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


I have observed a null-pointer access in w1/slaves/w1_therm on my Raspberry
Pi running 3.18.5 with several DS18S20 temperature sensors. I have already
discussed the problem with Evgeniy.

@Evgeniy & David: sorry for re-sending my message, my email
accidentally contained a HTML part.

w1_therm: w1_slave_show checks if the sensor uses external power. If this
is the case, the mutex on dev->bus_mutex is unlocked while waiting 750 ms
for the sensor to convert the temperature. Before reading the temperature,
the mutex is again locked.

During this sleep-time, the sensor could get detached, for example by w1.c:
w1_search_process_cb not finding the sensor (*):
 !test_bit(W1_SLAVE_ACTIVE, &sl->flags) ==true.
This triggers w1_slave_detach, and hence w1_therm_remove_slave frees and
nulls sl->family_data.

w1_slave_show does not check if familiy_data is null after re-acquiring the
bus_mutex resulting in a null-ptr access when storing data.

After I've added checks for family_data!=0, I did not observe any more
crashes; the other data of struct w1_slave seem to be valid as long as any
thread executes w1_slave_show.

I have added debug-output to w1.c and w1_therm.c, here's a log of a
potential crash:

[184199.510227] w1_master_driver w1_bus_master2: w1_search_process_cb,
!W1_SLAVE_ACTIVE, calling w1_slave_detach
[184199.510276] w1_slave_driver 10-000802d9c9e4: w1_slave_detach
destroy_now 1
[184199.510297] w1_slave_driver 10-000802d9c9e4: w1_unref_slave refcnt 0
[184199.510321] w1_slave_driver 10-000802d9c9e4: w1_unref_slave: detaching
10-000802d9c9e4 [d5fb8800].
[184199.510347] w1_slave_driver 10-000802d9c9e4: w1_unref_slave ->
[184199.510365] w1_slave_driver 10-000802d9c9e4: w1_family_notify calling
[184199.510382] w1_slave_driver 10-000802d9c9e4: w1_therm_remove_slave
[184199.510400] w1_slave_driver 10-000802d9c9e4: w1_therm_remove_slave
refcnt -1
[184200.049745] w1_slave_driver 10-000802d9c9e4: w1_slave_show (after
sleep), family_data==0
[184200.137133] w1_slave_driver 10-000802d9c9e4: w1_slave_show (before
sleep), family_data==0
[184200.889551] w1_slave_driver 10-000802d9c9e4: w1_slave_show (after
sleep), family_data==0
[184200.930866] w1_slave_driver 10-000802d9c9e4: w1_slave_show (after
sleep), family_data==0
[184200.930907] w1_slave_driver 10-000802d9c9e4: Read failed CRC check
[184200.931002] w1_slave_driver 10-000802d9c9e4: w1_unref_slave ->
[184200.931169] w1 w1_unref_slave -> kfree

Note: When this crash happened, multiple threads were reading the sensor.

I could trigger the problem several times, and each time device_unregister
in w1_unref_slave was executed  *after*  w1_slave_show. In one case, the
logged time-difference between the first family_data==0 message and
device_unregister was about 8 seconds!
I have not observed a w1_slave_show call after w1_unref_slave (as long as
the device was not re-attached again).

>From my observation, the w1_slave data seem to be valid as long as
w1_slave_show is executed.
My guess is that the call of sysfs_remove_groups in w1_family_notify hits a
mutex (I did not add debug output here).

(*) On my tiny raspberry, this happens from time to time with high CPU and
external disc load (timing and/or electrical issues); it seems that the
sensor does not respond in time to the (periodic) search.

Please email me if you need further information.

Best regards,
Thorsten Bschorr

       reply	other threads:[~2015-02-23 17:09 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <>
2015-02-23 17:09     ` Thorsten Bschorr [this message]
2015-02-24  1:37       ` Fwd: w1/slaves/w1_therm: null-ptr access of sl->family_data David Fries
2015-02-25  9:28         ` Thorsten Bschorr
2015-02-27  8:43 ` [PATCH] Avoid null-pointer access in w1/slaves/w1_therm Thorsten.Bschorr
2015-02-28 20:17   ` David Fries
     [not found]     ` <>
2015-03-01  2:17       ` David Fries
2015-03-01 13:04         ` Thorsten Bschorr
2015-03-02  0:17           ` David Fries
2015-03-04 15:36             ` Евгений Поляков
2015-03-08 21:14               ` David Fries
2015-03-09 22:47                 ` Thorsten Bschorr
2015-03-09 23:09                   ` David Fries
2015-03-10  0:05                     ` Thorsten Bschorr
2015-03-10  0:34                       ` Thorsten Bschorr
2015-03-12  0:44                         ` David Fries
2015-03-10 13:52                     ` Evgeniy Polyakov
2015-03-12  0:54                       ` David Fries
2015-03-14 20:55                         ` Evgeniy Polyakov
2015-03-18  4:20                           ` David Fries
2015-03-18 15:18                             ` Evgeniy Polyakov
2015-03-19  0:09                               ` David Fries
     [not found]                                 ` <>
2015-04-16  3:51                                   ` David Fries
2015-04-16 11:57                                     ` Evgeniy Polyakov
     [not found]                                       ` <>
2015-04-17 12:55                                         ` Evgeniy Polyakov

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:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \

* 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 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).