Received-SPF: pass (google.com: domain of linux-kernel+bounces-86397-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <077c8417-03bf-8d61-5d3a-0aef91b55659@basealt.ru>
Date: Thu, 29 Feb 2024 12:20:18 +0300
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [PATCH net] gtp: fix use-after-free and null-ptr-deref in
 gtp_newlink()
Content-Language: en-US
To: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
 stable@vger.kernel.org
References: <20240228114703.465107-1-oficerovas@altlinux.org>
 <Zd_HAGqXSE6Nwcag@calendula>
From: Vasiliy Kovalev <kovalev@altlinux.org>
In-Reply-To: <Zd_HAGqXSE6Nwcag@calendula>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

29.02.2024 02:51, Pablo Neira Ayuso wrote:
> On Wed, Feb 28, 2024 at 02:47:03PM +0300, Alexander Ofitserov wrote:
>> The gtp_link_ops operations structure for the subsystem must be
>> registered after registering the gtp_net_ops pernet operations structure.
> 
> A fix for this was already applied, see:
> 
> commit 136cfaca22567a03bbb3bf53a43d8cb5748b80ec
> Author: Vasiliy Kovalev <kovalev@altlinux.org>
> Date:   Wed Feb 14 19:27:33 2024 +0300
> 
>      gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()
> 
>> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
>> index 2129ae42c7030..0ddec4cc84093 100644
>> --- a/drivers/net/gtp.c
>> +++ b/drivers/net/gtp.c
>> @@ -1903,26 +1903,26 @@ static int __init gtp_init(void)
>>   
>>   	get_random_bytes(&gtp_h_initval, sizeof(gtp_h_initval));
>>   
>> -	err = rtnl_link_register(&gtp_link_ops);
>> +	err = register_pernet_subsys(&gtp_net_ops);
>>   	if (err < 0)
>>   		goto error_out;
> 
> BTW, I like that this calls register_pernet_subsys() before
> rtnl_link_register(), where a rtnetlink request could come before
> pernet is set up.
> 
>> -	err = register_pernet_subsys(&gtp_net_ops);
>> +	err = rtnl_link_register(&gtp_link_ops);
>>   	if (err < 0)
>> -		goto unreg_rtnl_link;
>> +		goto unreg_pernet_subsys;
>>   
>>   	err = genl_register_family(&gtp_genl_family);
>>   	if (err < 0)
>> -		goto unreg_pernet_subsys;
>> +		goto unreg_rtnl_link;
>>   
>>   	pr_info("GTP module loaded (pdp ctx size %zd bytes)\n",
>>   		sizeof(struct pdp_ctx));
>>   	return 0;
>>   
>> -unreg_pernet_subsys:
>> -	unregister_pernet_subsys(&gtp_net_ops);
>>   unreg_rtnl_link:
>>   	rtnl_link_unregister(&gtp_link_ops);
>> +unreg_pernet_subsys:
>> +	unregister_pernet_subsys(&gtp_net_ops);
>>   error_out:
>>   	pr_err("error loading GTP module loaded\n");
>>   	return err;
>> -- 
>> 2.42.1
>>
>>

This patch fixes another problem, but a similar one, since the sequence 
is incorrect when registering subsystems.

Initially, the registration sequence in the gtp module was as follows:

1) rtnl_link_register();

2) genl_register_family();

3) register_pernet_subsys();

During debugging of the module, when starting the syzkaller reproducer, 
it turned out that after genl_register_family() (2),

without waiting for register_pernet_subsys()(3), the .dumpit  event is 
triggered, in which the data of the unregistered pernet subsystem is 
accessed.

That is, the bug was fixed by the commit

136cfaca2256 ("gtp: fix use-after-free and null-ptr-deref in 
gtp_genl_dump_pdp()") [1]

and the registration sequence became as follows:

1) rtnl_link_register();

2) register_pernet_subsys();

3) genl_register_family();

However, syzkaller has discovered another problem:

after registering rtnl_link_register, the .newlink event is triggered, 
in which the data of the unregistered pernet subsystem is accessed.

This problem is reproducible on current stable kernels and the latest 
upstream kernel 6.8-rc6, in which the patch 136cfaca2256 [1] is applied.

Therefore, the correct sequence should be as follows:

1) register_pernet_subsys();

2) rtnl_link_register();

3) genl_register_family();

The proposed patch is developed on top of the commit changes [1], does 
not conflict with it and fixes the described bug.

[1] 
https://lore.kernel.org/lkml/20240220160434.29bcaf43@kernel.org/T/#mb1f72c2ad57b7ea6d47333e8616beccf8bce0e23

-- 
Regards,
Vasiliy Kovalev