linux-kernel - Re: [PATCH] can: etas_es58x: change opened_channel_cnt's type from atomic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220212155733.gfwkcs7xcwlqzi6r@pengutronix.de>
Date:   Sat, 12 Feb 2022 16:57:33 +0100
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Vincent Mailhol <mailhol.vincent@...adoo.fr>
Cc:     netdev@...r.kernel.org, linux-can@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: [PATCH] can: etas_es58x: change opened_channel_cnt's type from
 atomic_t to u8

On 12.02.2022 20:27:13, Vincent Mailhol wrote:
> The driver uses an atomic_t variable: es58x_device:opened_channel_cnt
> to keep track of the number of opened channels in order to only
> allocate memory for the URBs when this count changes from zero to one.
> 
> While the intent was to prevent race conditions, the choice of an
> atomic_t turns out to be a bad idea for several reasons:
> 
>   - implementation is incorrect and fails to decrement
>     opened_channel_cnt when the URB allocation fails as reported in
>     [1].
> 
>   - even if opened_channel_cnt were to be correctly decremented,
>     atomic_t is insufficient to cover edge cases: there can be a race
>     condition in which 1/ a first process fails to allocate URBs
>     memory 2/ a second process enters es58x_open() before the first
>     process does its cleanup and decrements opened_channed_cnt. In
>     which case, the second process would successfully return despite
>     the URBs memory not being allocated.
> 
>   - actually, any kind of locking mechanism was useless here because
>     it is redundant with the network stack big kernel lock
>     (a.k.a. rtnl_lock) which is being hold by all the callers of
>     net_device_ops:ndo_open() and net_device_ops:ndo_close(). c.f. the
>     ASSERST_RTNL() calls in __dev_open() [2] and __dev_close_many()
>     [3].
> 
> The atmomic_t is thus replaced by a simple u8 type and the logic to
> increment and decrement es58x_device:opened_channel_cnt is simplified
> accordingly fixing the bug reported in [1]. We do not check again for
> ASSERST_RTNL() as this is already done by the callers.
> 
> [1] https://lore.kernel.org/linux-can/20220201140351.GA2548@kili/T/#u
> [2] https://elixir.bootlin.com/linux/v5.16/source/net/core/dev.c#L1463
> [3] https://elixir.bootlin.com/linux/v5.16/source/net/core/dev.c#L1541
> 
> Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X
> CAN USB interfaces")
> Reported-by: Dan Carpenter <dan.carpenter@...cle.com>
> Signed-off-by: Vincent Mailhol <mailhol.vincent@...adoo.fr>

Applied to can/testing.

I you (or someone else) wants to increase their patch count feel free to
convert the other USB CAN drivers from atomic_t to u8, too.

Thanks,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)