Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1476210 > unrolled thread

A potential race in drivers/staging/speakup/speakup.ko

Started byPavel Andrianov <andrianov@ispras.ru>
First post2016-09-05 11:00 +0200
Last post2016-09-05 12:40 +0200
Articles 6 — 2 participants

Back to article view | Back to linux.kernel

Contents

  A potential race in drivers/staging/speakup/speakup.ko Pavel Andrianov <andrianov@ispras.ru> - 2016-09-05 11:00 +0200
    Re: A potential race in drivers/staging/speakup/speakup.ko Samuel Thibault <samuel.thibault@ens-lyon.org> - 2016-09-05 11:50 +0200
      Re: A potential race in drivers/staging/speakup/speakup.ko Pavel Andrianov <andrianov@ispras.ru> - 2016-09-05 12:00 +0200
        Re: A potential race in drivers/staging/speakup/speakup.ko Samuel Thibault <samuel.thibault@ens-lyon.org> - 2016-09-05 12:00 +0200
          Re: A potential race in drivers/staging/speakup/speakup.ko Pavel Andrianov <andrianov@ispras.ru> - 2016-09-05 12:40 +0200
            Re: A potential race in drivers/staging/speakup/speakup.ko Samuel Thibault <samuel.thibault@ens-lyon.org> - 2016-09-05 12:40 +0200

#1476210 — A potential race in drivers/staging/speakup/speakup.ko

FromPavel Andrianov <andrianov@ispras.ru>
Date2016-09-05 11:00 +0200
SubjectA potential race in drivers/staging/speakup/speakup.ko
Message-ID<sdXV0-1pk-9@gated-at.bofh.it>
Hi!

There is a potential race in drivers/staging/speakup/speakup.ko.
All operations with global pointers buff_in and buff_out are performed 
without any locks. Thus, a simultaneous write (via synth_buffer_clear or 
synth_buffer_add) to the pointers may lead to inconsistent data.

Should a local lock be used here?

-- 
Pavel Andrianov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: andrianov@ispras.ru

[toc] | [next] | [standalone]

#1476238

FromSamuel Thibault <samuel.thibault@ens-lyon.org>
Date2016-09-05 11:50 +0200
Message-ID<sdYHo-1W2-15@gated-at.bofh.it>
In reply to#1476210
Hello,

Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote:
> There is a potential race in drivers/staging/speakup/speakup.ko.
> All operations with global pointers buff_in and buff_out are performed
> without any locks. Thus, a simultaneous write (via synth_buffer_clear or
> synth_buffer_add) to the pointers may lead to inconsistent data.
> 
> Should a local lock be used here?

AIUI, all callers of these functions have speakup_info.spinlock held.

Samuel

[toc] | [prev] | [next] | [standalone]

#1476253

FromPavel Andrianov <andrianov@ispras.ru>
Date2016-09-05 12:00 +0200
Message-ID<sdYR6-209-61@gated-at.bofh.it>
In reply to#1476238
05.09.2016 12:43, Samuel Thibault пишет:
> Hello,
>
> Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote:
>> There is a potential race in drivers/staging/speakup/speakup.ko.
>> All operations with global pointers buff_in and buff_out are performed
>> without any locks. Thus, a simultaneous write (via synth_buffer_clear or
>> synth_buffer_add) to the pointers may lead to inconsistent data.
>>
>> Should a local lock be used here?
>
> AIUI, all callers of these functions have speakup_info.spinlock held.
>
> Samuel
>

Regard a call stack

-> synth_direct_store
   -> synth_printf
     -> synth_buffer_add

The functions have not held speakup_info.spinlock.

-- 
Pavel Andrianov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: andrianov@ispras.ru

[toc] | [prev] | [next] | [standalone]

#1476259

FromSamuel Thibault <samuel.thibault@ens-lyon.org>
Date2016-09-05 12:00 +0200
Message-ID<sdYR7-209-93@gated-at.bofh.it>
In reply to#1476253
Pavel Andrianov, on Mon 05 Sep 2016 12:54:10 +0300, wrote:
> 05.09.2016 12:43, Samuel Thibault пишет:
> >Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote:
> >>There is a potential race in drivers/staging/speakup/speakup.ko.
> >>All operations with global pointers buff_in and buff_out are performed
> >>without any locks. Thus, a simultaneous write (via synth_buffer_clear or
> >>synth_buffer_add) to the pointers may lead to inconsistent data.
> >>
> >>Should a local lock be used here?
> >
> >AIUI, all callers of these functions have speakup_info.spinlock held.
> 
> Regard a call stack
> 
> -> synth_direct_store
>   -> synth_printf
>     -> synth_buffer_add
> 
> The functions have not held speakup_info.spinlock.

Apparently there is currently no caller of synth_direct_store and
synth_store. But taking the lock here would be needed indeed.

Samuel

[toc] | [prev] | [next] | [standalone]

#1476290

FromPavel Andrianov <andrianov@ispras.ru>
Date2016-09-05 12:40 +0200
Message-ID<sdZtL-2y1-5@gated-at.bofh.it>
In reply to#1476259
05.09.2016 12:56, Samuel Thibault пишет:
> Pavel Andrianov, on Mon 05 Sep 2016 12:54:10 +0300, wrote:
>> 05.09.2016 12:43, Samuel Thibault пишет:
>>> Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote:
>>>> There is a potential race in drivers/staging/speakup/speakup.ko.
>>>> All operations with global pointers buff_in and buff_out are performed
>>>> without any locks. Thus, a simultaneous write (via synth_buffer_clear or
>>>> synth_buffer_add) to the pointers may lead to inconsistent data.
>>>>
>>>> Should a local lock be used here?
>>>
>>> AIUI, all callers of these functions have speakup_info.spinlock held.
>>
>> Regard a call stack
>>
>> -> synth_direct_store
>>   -> synth_printf
>>     -> synth_buffer_add
>>
>> The functions have not held speakup_info.spinlock.
>
> Apparently there is currently no caller of synth_direct_store and
> synth_store. But taking the lock here would be needed indeed.
>
> Samuel
>

synth_direct_store may be called via device_attributes interface. In 
which function the lock should be added?

-- 
Pavel Andrianov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: andrianov@ispras.ru

[toc] | [prev] | [next] | [standalone]

#1476294

FromSamuel Thibault <samuel.thibault@ens-lyon.org>
Date2016-09-05 12:40 +0200
Message-ID<sdZtM-2y1-25@gated-at.bofh.it>
In reply to#1476290
Pavel Andrianov, on Mon 05 Sep 2016 13:33:33 +0300, wrote:
> synth_direct_store may be called via device_attributes interface.

Ah, right.

> In which function the lock should be added?

That'd be synth_direct_store then, around the while loop.

Samuel

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web