Re: Possible race in c4.ko

[Carsten Paeth]

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@xxxxxxxxx