netdev - Re: [PATCH net-next v3 3/9] Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock

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]

Message-ID: <CANn89iL7tdEr6_gpQCsLncNW4d2NonTVR0pTgxY4-O556ZQiJg@mail.gmail.com>
Date: Tue, 15 Oct 2024 10:04:10 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: ignat@...udflare.com, alex.aring@...il.com, alibuda@...ux.alibaba.com, 
	davem@...emloft.net, dsahern@...nel.org, johan.hedberg@...il.com, 
	kernel-team@...udflare.com, kuba@...nel.org, linux-bluetooth@...r.kernel.org, 
	linux-can@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-wpan@...r.kernel.org, luiz.dentz@...il.com, marcel@...tmann.org, 
	miquel.raynal@...tlin.com, mkl@...gutronix.de, netdev@...r.kernel.org, 
	pabeni@...hat.com, socketcan@...tkopp.net, stefan@...enfreihafen.org, 
	willemdebruijn.kernel@...il.com
Subject: Re: [PATCH net-next v3 3/9] Bluetooth: RFCOMM: avoid leaving dangling
 sk pointer in rfcomm_sock_alloc()

On Mon, Oct 14, 2024 at 11:30 PM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
>
> From: Ignat Korchagin <ignat@...udflare.com>
> Date: Mon, 14 Oct 2024 16:38:02 +0100
> > bt_sock_alloc() attaches allocated sk object to the provided sock object.
> > If rfcomm_dlc_alloc() fails, we release the sk object, but leave the
> > dangling pointer in the sock object, which may cause use-after-free.
> >
> > Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().
> >
> > Signed-off-by: Ignat Korchagin <ignat@...udflare.com>
>
> Reviewed-by: Kuniyuki Iwashima <kuniyu@...zon.com>

Reviewed-by: Eric Dumazet <edumazet@...gle.com>