netdev - Re: [PATCH net-next v2 1/3] net: ipvlan: fix potential UAF problem for phy

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]

Date:   Fri, 18 Mar 2022 10:53:11 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Ziyang Xuan <william.xuanziyang@...wei.com>
Cc:     <davem@...emloft.net>, <netdev@...r.kernel.org>,
        <edumazet@...gle.com>, <sakiwit@...il.com>,
        <sainath.grandhi@...el.com>, <maheshb@...gle.com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v2 1/3] net: ipvlan: fix potential UAF problem
 for phy_dev

On Fri, 18 Mar 2022 09:57:47 +0800 Ziyang Xuan wrote:
> Add the reference operation to phy_dev of ipvlan to avoid
> the potential UAF problem under the following known scenario:
> 
> Someone module puts the NETDEV_UNREGISTER event handler to a
> work, and phy_dev is accessed in the work handler. But when
> the work is excuted, phy_dev has been destroyed because upper
> ipvlan did not get reference to phy_dev correctly.
> 
> That likes as the scenario occurred by
> commit 563bcbae3ba2 ("net: vlan: fix a UAF in vlan_dev_real_dev()").

There is no equivalent of vlan_dev_real_dev() for ipvlan, AFAICT.
The definition of struct ipvl_dev is private to the driver. I don't 
see how a UAF can happen here.

You should either clearly explain how the bug could happen or clearly
state that there is no possibility of the bug for this driver, and the
patch is just future proofing.

If the latter is the case we should drop the Fixes tag and prevent this
patch from getting backported into stable.

> Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.")
> Signed-off-by: Ziyang Xuan <william.xuanziyang@...wei.com>