linux-kernel - Re: [PATCH 4.19 027/168] Bluetooth: add a mutex lock to avoid UAF in do_enale

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:   Tue, 18 Aug 2020 11:53:18 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Pavel Machek <pavel@...x.de>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        syzbot+96414aa0033c363d8458@...kaller.appspotmail.com,
        Lihong Kou <koulihong@...wei.com>,
        Marcel Holtmann <marcel@...tmann.org>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 027/168] Bluetooth: add a mutex lock to avoid UAF in
 do_enale_set

On Tue, Aug 18, 2020 at 11:40:25AM +0200, Pavel Machek wrote:
> Hi!
> 
> > From: Lihong Kou <koulihong@...wei.com>
> > 
> > [ Upstream commit f9c70bdc279b191da8d60777c627702c06e4a37d ]
> > 
> > In the case we set or free the global value listen_chan in
> > different threads, we can encounter the UAF problems because
> > the method is not protected by any lock, add one to avoid
> > this bug.
> 
> For this to be safe, bt_6lowpan_exit() needs same handling, no?
> 
> Signed-off-by: Pavel Machek (CIP) <pavel@...x.de>
> 
> diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
> index 9a75f9b00b51..2402ef5ac072 100644
> --- a/net/bluetooth/6lowpan.c
> +++ b/net/bluetooth/6lowpan.c
> @@ -1304,10 +1304,12 @@ static void __exit bt_6lowpan_exit(void)
>  	debugfs_remove(lowpan_enable_debugfs);
>  	debugfs_remove(lowpan_control_debugfs);
>  
> +	mutex_lock(&set_lock);
>  	if (listen_chan) {
>  		l2cap_chan_close(listen_chan, 0);
>  		l2cap_chan_put(listen_chan);
>  	}
> +	mutex_unlock(&set_lock);
>  
>  	disconnect_devices();
>  
> 
> 

Why you are sending this in this format seems very odd to me, you know
better...