Messages in this thread |  | | Date | Wed, 16 Aug 2017 06:55:37 +0200 | From | Carsten Paeth <> | Subject | Re: Possible race in c4.ko |
| |
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
|  |