From: "Ziyang Xuan (William)" <william.xuanziyang@huawei.com>
To: Eric Dumazet <edumazet@google.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>, <socketcan@hartkopp.net>,
<davem@davemloft.net>, <kuba@kernel.org>, <pabeni@redhat.com>,
<linux-can@vger.kernel.org>, <netdev@vger.kernel.org>,
<penguin-kernel@i-love.sakura.ne.jp>
Subject: Re: [PATCH net v3] can: raw: fix receiver memory leak
Date: Thu, 3 Aug 2023 08:43:56 +0800 [thread overview]
Message-ID: <df3afb62-061e-a40f-b872-c9eb414455bb@huawei.com> (raw)
In-Reply-To: <CANn89iJ8jFxGo0d_8KnM2f=Xbh=iqb=+zcGn+U6PypuqNdWBUQ@mail.gmail.com>
>>> On Wed, Jul 19, 2023 at 6:41 AM Ziyang Xuan (William)
>>> <william.xuanziyang@huawei.com> wrote:
>>>>
>>>>> On Mon, Jul 17, 2023 at 9:27 AM Marc Kleine-Budde <mkl@pengutronix.de> wrote:
>>>>>>
>>>>>> On 11.07.2023 09:17:37, Ziyang Xuan wrote:
>>>>>>> Got kmemleak errors with the following ltp can_filter testcase:
>>>>>>>
>>>>>>> for ((i=1; i<=100; i++))
>>>>>>> do
>>>>>>> ./can_filter &
>>>>>>> sleep 0.1
>>>>>>> done
>>>>>>>
>>>>>>> ==============================================================
>>>>>>> [<00000000db4a4943>] can_rx_register+0x147/0x360 [can]
>>>>>>> [<00000000a289549d>] raw_setsockopt+0x5ef/0x853 [can_raw]
>>>>>>> [<000000006d3d9ebd>] __sys_setsockopt+0x173/0x2c0
>>>>>>> [<00000000407dbfec>] __x64_sys_setsockopt+0x61/0x70
>>>>>>> [<00000000fd468496>] do_syscall_64+0x33/0x40
>>>>>>> [<00000000b7e47d51>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
>>>>>>>
>>>>>>> It's a bug in the concurrent scenario of unregister_netdevice_many()
>>>>>>> and raw_release() as following:
>>>>>>>
>>>>>>> cpu0 cpu1
>>>>>>> unregister_netdevice_many(can_dev)
>>>>>>> unlist_netdevice(can_dev) // dev_get_by_index() return NULL after this
>>>>>>> net_set_todo(can_dev)
>>>>>>> raw_release(can_socket)
>>>>>>> dev = dev_get_by_index(, ro->ifindex); // dev == NULL
>>>>>>> if (dev) { // receivers in dev_rcv_lists not free because dev is NULL
>>>>>>> raw_disable_allfilters(, dev, );
>>>>>>> dev_put(dev);
>>>>>>> }
>>>>>>> ...
>>>>>>> ro->bound = 0;
>>>>>>> ...
>>>>>>>
>>>>>>> call_netdevice_notifiers(NETDEV_UNREGISTER, )
>>>>>>> raw_notify(, NETDEV_UNREGISTER, )
>>>>>>> if (ro->bound) // invalid because ro->bound has been set 0
>>>>>>> raw_disable_allfilters(, dev, ); // receivers in dev_rcv_lists will never be freed
>>>>>>>
>>>>>>> Add a net_device pointer member in struct raw_sock to record bound can_dev,
>>>>>>> and use rtnl_lock to serialize raw_socket members between raw_bind(), raw_release(),
>>>>>>> raw_setsockopt() and raw_notify(). Use ro->dev to decide whether to free receivers in
>>>>>>> dev_rcv_lists.
>>>>>>>
>>>>>>> Fixes: 8d0caedb7596 ("can: bcm/raw/isotp: use per module netdevice notifier")
>>>>>>> Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
>>>>>>> Reviewed-by: Oliver Hartkopp <socketcan@hartkopp.net>
>>>>>>> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
>>>>>>
>>>>>> Added to linux-can/testing.
>>>>>>
>>>>>
>>>>> This patch causes three syzbot LOCKDEP reports so far.
>>>>
>>>> Hello Eric,
>>>>
>>>> Is there reproducer? I want to understand the specific root cause.
>>>>
>>>
>>> No repro yet, but simply look at other functions in net/can/raw.c
>>>
>>> You must always take locks in the same order.
>>>
>>> raw_bind(), raw_setsockopt() use:
>>>
>>> rtnl_lock();
>>> lock_sock(sk);
>>>
>>> Therefore, raw_release() must _also_ use the same order, or risk deadlock.
>>>
>>> Please build a LOCKDEP enabled kernel, and run your tests ?
>>
>> I know now. This needs raw_bind() and raw_setsockopt() concurrent with raw_release().
>> And there is not the scenario in my current testcase. I did not get it. I will try to
>> reproduce it and add the testcase.
>>
>> Thank you for your patient explanation.
>
> Another syzbot report is firing because of your patch
>
> Apparently we store in ro->dev a pointer to a netdev without holding a
> refcount on it.
> .
Hello Eric,
Is there a syzbot link or reproducer can be provided?
Thank you!
William Xuan
>
next prev parent reply other threads:[~2023-08-03 0:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 1:17 [PATCH net v3] can: raw: fix receiver memory leak Ziyang Xuan
2023-07-11 6:45 ` Oliver Hartkopp
2023-07-17 7:27 ` Marc Kleine-Budde
2023-07-19 3:31 ` Eric Dumazet
2023-07-19 4:41 ` Ziyang Xuan (William)
2023-07-19 5:04 ` Eric Dumazet
2023-07-19 7:49 ` Ziyang Xuan (William)
2023-08-02 17:48 ` Eric Dumazet
2023-08-03 0:43 ` Ziyang Xuan (William) [this message]
2023-08-03 7:11 ` Eric Dumazet
2023-08-04 11:47 ` Oliver Hartkopp
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=df3afb62-061e-a40f-b872-c9eb414455bb@huawei.com \
--to=william.xuanziyang@huawei.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=socketcan@hartkopp.net \
/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;
as well as URLs for NNTP newsgroup(s).