From: "Behme Dirk (CM/ESO2)" <dirk.behme@de.bosch.com>
To: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: "s.shtylyov@omp.ru" <s.shtylyov@omp.ru>,
"lee@kernel.org" <lee@kernel.org>,
"linyunsheng@huawei.com" <linyunsheng@huawei.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"edumazet@google.com" <edumazet@google.com>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"richardcochran@gmail.com" <richardcochran@gmail.com>,
"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
"geert+renesas@glider.be" <geert+renesas@glider.be>,
"magnus.damm@gmail.com" <magnus.damm@gmail.com>,
Biju Das <biju.das.jz@bp.renesas.com>,
"wsa+renesas@sang-engineering.com"
<wsa+renesas@sang-engineering.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"hackerzheng666@gmail.com" <hackerzheng666@gmail.com>,
"1395428693sheep@gmail.com" <1395428693sheep@gmail.com>,
"alex000young@gmail.com" <alex000young@gmail.com>,
Zheng Wang <zyytlz.wz@163.com>, Jakub Kicinski <kuba@kernel.org>
Subject: RE: [PATCH v4] net: ravb: Fix possible UAF bug in ravb_remove
Date: Fri, 13 Oct 2023 08:04:45 +0200 [thread overview]
Message-ID: <93811ef2-8df9-de21-3f8d-296400ec2ba5@de.bosch.com> (raw)
In-Reply-To: <TYBPR01MB5341D3791E728E3D9EFC25D4D8D3A@TYBPR01MB5341.jpnprd01.prod.outlook.com>
Hi,
On 12.10.2023 10:39, Yoshihiro Shimoda wrote:
> Hello Behme,
>
>> From: Behme Dirk (CM/ESO2), Sent: Tuesday, October 10, 2023 9:59 PM
>>
>> On 26.07.2023 05:19, Jakub Kicinski wrote:
>> ...
>>> The fact that ravb_tx_timeout_work doesn't take any locks seems much
>>> more suspicious.
>> Does anybody plan to look into this, too?
>
> I believe my fixed patch [1] resolved this issue too.
I'm not an expert of this driver nor the network stack, so sorry if I'm
totally wrong here ;) But somehow this answer confuses me. Let me explain:
What you did with [1] is to stop/cancel the workqueue in ravb_close().
That's fine. But that is at driver's close time.
What's about driver's normal runtime? What I understood is that
ravb_tx_timeout_work() might run totally asynchronously to the rest of
the driver. And therefore needs locking/protection/synchronization if it
uses resources of the driver which are used elsewhere in the driver, too.
I think this is exactly what is described with:
> ---
> Simplest fix I can think of is to take a reference on the netdev before
> scheduling the work, and then check if it's still registered in the work
> itself. Wrap the timeout work in rtnl_lock() to avoid any races there.
> ---
So, where is above done? Not at close time, but at normal run time of
the driver?
Best regards
Dirk
> Sergey suggested to add cancel_work_sync() into the ravb_close () [3].
> And I investigated calltrace, and then the ravb_close() is under rtnl_lock() [4]
> like below:
> -----------------------------------------------------------------------
> ravb_remove() calls unregister_netdev().
> -> unregister_netdev() calls rtnl_lock() and unregister_netdevice().
> --> unregiter_netdevice_queue()
> ---> unregiter_netdevice_many()
> ----> unregiter_netdevice_many_notify().
> -----> dev_close_many()
> ------> __dev_close_many()
> -------> ops->ndo_stop()
>
> ravb_close() calls phy_stop()
> -> phy_state_machine() with PHY_HALTED
> --> phy_link_down()
> ---> phy_link_change()
> ----> netif_carrier_off()
> -----------------------------------------------------------------------
>
> So, during cancel_work_sync() is waiting for canceling the workqueue in ravb_close(),
> it's under rtnl_lock() so that no additional locks are needed in ravb_tx_timeout_work().
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=3971442870713de527684398416970cf025b4f89
> [2] https://lore.kernel.org/netdev/20230727164820.48c9e685@kernel.org/
> [3] https://lore.kernel.org/netdev/607f4fe4-5a59-39dd-71c2-0cf769b48187@omp.ru/
> [4] https://lore.kernel.org/netdev/OSYPR01MB53341CFDBB49A3BA41A6752CD8F9A@OSYPR01MB5334.jpnprd01.prod.outlook.com/
>
> Best regards,
> Yoshihiro Shimoda
>
>> Best regards
>>
>> Dirk
--
======================================================================
Dirk Behme Robert Bosch Car Multimedia GmbH
CM/ESO2
Phone: +49 5121 49-3274 Dirk Behme
Fax: +49 711 811 5053274 PO Box 77 77 77
mailto:dirk.behme@de.bosch.com D-31132 Hildesheim - Germany
Bosch Group, Car Multimedia (CM)
Engineering SW Operating Systems 2 (ESO2)
Robert Bosch Car Multimedia GmbH - Ein Unternehmen der Bosch Gruppe
Sitz: Hildesheim
Registergericht: Amtsgericht Hildesheim HRB 201334
Aufsichtsratsvorsitzender: Dr. Dirk Hoheisel
Geschäftsführung: Dr. Steffen Berns;
Dr. Sven Ost, Jörg Pollak, Dr. Walter Schirm
======================================================================
next prev parent reply other threads:[~2023-10-13 6:05 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 3:00 Zheng Wang
2023-07-26 3:19 ` Jakub Kicinski
2023-07-27 8:21 ` Paolo Abeni
2023-07-27 18:48 ` Sergey Shtylyov
2023-07-27 23:48 ` Jakub Kicinski
2023-07-28 10:32 ` Simon Horman
2023-09-20 2:37 ` Yoshihiro Shimoda
2023-09-29 20:23 ` Sergey Shtylyov
2023-10-02 0:11 ` Yoshihiro Shimoda
2023-10-03 19:39 ` Sergey Shtylyov
2023-10-04 5:05 ` Yoshihiro Shimoda
2023-10-10 12:59 ` Behme Dirk (CM/ESO2)
2023-10-12 8:39 ` Yoshihiro Shimoda
2023-10-13 6:04 ` Behme Dirk (CM/ESO2) [this message]
2023-10-13 8:32 ` Yoshihiro Shimoda
2023-08-15 10:08 ` Lee Jones
2023-08-29 13:46 ` Lee Jones
2023-08-30 4:30 ` Zheng Hacker
2023-08-31 6:46 ` Zheng Hacker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=93811ef2-8df9-de21-3f8d-296400ec2ba5@de.bosch.com \
--to=dirk.behme@de.bosch.com \
--cc=1395428693sheep@gmail.com \
--cc=alex000young@gmail.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=geert+renesas@glider.be \
--cc=hackerzheng666@gmail.com \
--cc=kuba@kernel.org \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linyunsheng@huawei.com \
--cc=magnus.damm@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=s.shtylyov@omp.ru \
--cc=wsa+renesas@sang-engineering.com \
--cc=yoshihiro.shimoda.uh@renesas.com \
--cc=zyytlz.wz@163.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®