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


Groups > linux.kernel > #1712183 > unrolled thread

Possible race in c4.ko

Started byAnton Volkov <avolkov@ispras.ru>
First post2017-08-15 15:30 +0200
Last post2017-08-16 07:10 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel


Contents

  Possible race in c4.ko Anton Volkov <avolkov@ispras.ru> - 2017-08-15 15:30 +0200
    Re: Possible race in c4.ko Carsten Paeth <calle@calle.in-berlin.de> - 2017-08-16 07:10 +0200

#1712183 — Possible race in c4.ko

FromAnton Volkov <avolkov@ispras.ru>
Date2017-08-15 15:30 +0200
SubjectPossible race in c4.ko
Message-ID<ueK4W-1Pe-9@gated-at.bofh.it>
Hello.

While searching for races in the Linux kernel I've come across 
"drivers/isdn/hardware/avm/c4.ko" module. Here is a question that I came 
up with while analyzing results. Lines are given using the info from 
Linux v4.12.

Consider the following case:

Thread 1:                  Thread 2:
c4_probe
->c4_add_card
     request_irq()
                            c4_interrupt
                            ->c4_handle_interrupt
                              ->c4_handle_rx
     card->cardnr = ...         cidx = f(card->cardnr)
     (c4.c: line 1227)          (c4.c: line 526)
                                if (cidx >= card->nlogcontr) cidx = 0;
                                ctrl = &card->ctrlinfo[cidx].capi_ctrl

card->cardnr is 0 until it is initialized in c4_add_card(). If at the 
moment of read access in c4_handle_rx() it is still 0, cidx may then be 
assigned an undesirable value and wrong controller may handle messages. 
Is this case feasible from your point of view?

Thank you for your time.

-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avolkov@ispras.ru

[toc] | [next] | [standalone]


#1712682

FromCarsten Paeth <calle@calle.in-berlin.de>
Date2017-08-16 07:10 +0200
Message-ID<ueYKB-2PV-3@gated-at.bofh.it>
In reply to#1712183
Hello Anton,

Thanks for reviewing the code.

This would be right, if the c4 could rise an interrupt at this moment ...

After a reset with c4_reset(), the card will not generate an interrupt,
until firmware has been loaded and the SEND_INIT message has been sent.
c4_load_firmware() -> c4_send_init() sets the card number in the card.

Therefor it's not an issue.

best regards,

calle

Tue, Aug 15, 2017 at 04:22:16PM +0300, Anton Volkov schrieb:
> Hello.
> 
> While searching for races in the Linux kernel I've come across
> "drivers/isdn/hardware/avm/c4.ko" module. Here is a question that I came up
> with while analyzing results. Lines are given using the info from Linux
> v4.12.
> 
> Consider the following case:
> 
> Thread 1:                  Thread 2:
> c4_probe
> ->c4_add_card
>     request_irq()
>                            c4_interrupt
>                            ->c4_handle_interrupt
>                              ->c4_handle_rx
>     card->cardnr = ...         cidx = f(card->cardnr)
>     (c4.c: line 1227)          (c4.c: line 526)
>                                if (cidx >= card->nlogcontr) cidx = 0;
>                                ctrl = &card->ctrlinfo[cidx].capi_ctrl
> 
> card->cardnr is 0 until it is initialized in c4_add_card(). If at the moment
> of read access in c4_handle_rx() it is still 0, cidx may then be assigned an
> undesirable value and wrong controller may handle messages. Is this case
> feasible from your point of view?
> 
> Thank you for your time.
> 
> -- Anton Volkov
> Linux Verification Center, ISPRAS
> web: http://linuxtesting.org
> e-mail: avolkov@ispras.ru

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web