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: [email protected]
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: [email protected]