netdev - Re: [PATCH net-next 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] [day] [month] [year] [list]

Date:   Tue, 15 Mar 2022 10:21:56 +0800
From:   "Ziyang Xuan (William)" <william.xuanziyang@...wei.com>
To:     Eric Dumazet <edumazet@...gle.com>
CC:     David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>, <sakiwit@...il.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 1/3] net: ipvlan: fix potential UAF problem for
 phy_dev

> On Mon, Mar 14, 2022 at 3:54 AM Ziyang Xuan
> <william.xuanziyang@...wei.com> 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.
> 
> Can you name the module deferring NETDEV_UNREGISTER to a work queue ?

The one I know is nb_netdevice netdevice notifier of roce_gid_mgmt.
It will trigger vlan's real_dev UAF. It is a syzbot problem.
See details:
https://syzkaller.appspot.com/bug?extid=e4df4e1389e28972e955

> 
> This sounds like a bug to me.
> 
>>
>> That likes as the scenario occurred by
>> commit 563bcbae3ba2 ("net: vlan: fix a UAF in vlan_dev_real_dev()").
> 
> Mentioning a commit that added a bug and many other commits trying to
> fix it is a bit unfortunate.

Yes, I am sorry for that. I will keep improving the quality of my code.

The related problems have solved by the series patches of
commit faab39f63c1f ("net: allow out-of-order netdev unregistration").
So I think it is the right time to fix other modules' potential problem.

> 
> Can you instead add a Fixes: tag ?

The potential problem exists since macvlan and ipvlan were added.

> 
> Do you have a repro to trigger the bug ?

For macvlan and ipvlan, there are not repros now. I think it is necessary
to give a right logic to cope with the constant evolution of the kernel.

> 
>>
>> Signed-off-by: Ziyang Xuan <william.xuanziyang@...wei.com>
>> ---
>>  drivers/net/ipvlan/ipvlan_main.c | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
>> index 696e245f6d00..dcdc01403f22 100644
>> --- a/drivers/net/ipvlan/ipvlan_main.c
>> +++ b/drivers/net/ipvlan/ipvlan_main.c
>> @@ -158,6 +158,10 @@ static int ipvlan_init(struct net_device *dev)
>>         }
>>         port = ipvlan_port_get_rtnl(phy_dev);
>>         port->count += 1;
>> +
>> +       /* Get ipvlan's reference to phy_dev */
>> +       dev_hold(phy_dev);
>> +
>>         return 0;
>>  }
>>
>> @@ -665,6 +669,14 @@ void ipvlan_link_delete(struct net_device *dev, struct list_head *head)
>>  }
>>  EXPORT_SYMBOL_GPL(ipvlan_link_delete);
>>
>> +static void ipvlan_dev_free(struct net_device *dev)
>> +{
>> +       struct ipvl_dev *ipvlan = netdev_priv(dev);
>> +
>> +       /* Get rid of the ipvlan's reference to phy_dev */
>> +       dev_put(ipvlan->phy_dev);
>> +}
>> +
>>  void ipvlan_link_setup(struct net_device *dev)
>>  {
>>         ether_setup(dev);
>> @@ -674,6 +686,7 @@ void ipvlan_link_setup(struct net_device *dev)
>>         dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
>>         dev->netdev_ops = &ipvlan_netdev_ops;
>>         dev->needs_free_netdev = true;
>> +       dev->priv_destructor = ipvlan_dev_free;
>>         dev->header_ops = &ipvlan_header_ops;
>>         dev->ethtool_ops = &ipvlan_ethtool_ops;
>>  }
>> --
>> 2.25.1
>>
> .
>