[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 19 Jun 2021 13:23:24 -0300
From: Thadeu Lima de Souza Cascardo <cascardo@...onical.com>
To: oss-security@...ts.openwall.com
Cc: Oliver Hartkopp <socketcan@...tkopp.net>,
Marc Kleine-Budde <mkl@...gutronix.de>,
Norbert Slusarek <nslusarek@....net>
Subject: Re: CVE-2021-3609: Race condition in net/can/bcm.c leads to local
privilege escalation
On Sat, Jun 19, 2021 at 04:40:53PM +0200, Norbert Slusarek wrote:
> Hello,
>
> this is an announcement for the recently reported bug (CVE-2021-3609)
> in the CAN BCM networking protocol in the Linux kernel ranging from
> version 2.6.25 to mainline 5.13-rc6.
> The vulnerability is a race condition in net/can/bcm.c allowing for local
> privilege escalation to root. The issue was initially reported by syzbot and
> proven to be exploitable by Norbert Slusarek.
>
> The CAN BCM networking protocol allows to register a CAN message receiver for a
> specified socket. The function bcm_rx_handler() is run for incoming CAN messages.
> Simultaneously to running this function, the socket can be closed and
> bcm_release() will be called. Inside bcm_release(), struct bcm_op and
> struct bcm_sock are freed while bcm_rx_handler() is still running,
> finally leading to multiple use-after-free's.
>
> Reproduction
> ------------
>
> - setup unprivileged user namespace
> - setup vcan network interface
> - open two CAN BCM sockets and connect each to the interface
> - call sendmsg() on socket 1 with RX_SETUP to setup CAN receiver
> - call sendmsg() on socket 2 to send message to socket 1
>
> Here comes the race condition:
>
> - bcm_rx_handler() is run automatically for socket 1 to receive the message
> - call close() -> bcm_release() on socket 1 to free struct bcm_op and struct bcm_sock
>
> => bcm_rx_handler() is still running and will access struct bcm_op and struct
> bcm_sock which were previously freed
>
> Exploitation
> ------------
>
> My exploitation attempt concentrates on kernels with version >= 5.4-rc1
> since commit bf74aa86e111 ("can: bcm: switch timer to HRTIMER_MODE_SOFT and
> remove hrtimer_tasklet"). I didn't investigate into exploiting kernels older
> than 5.4-rc1 which used tasklets, nevertheless exploitation on older kernels
> looks feasible as well. My specific exploitation approach was adjusted to work
> with Ubuntu 20.04.02 LTS but other known distributions could also be targeted.
>
> More exploitation details can be found at
>
> https://github.com/nrb547/kernel-exploitation/blob/main/cve-2021-3609/cve-2021-3609.md
>
> or in the attachments (plain text and attached image).
>
> Regards,
> Norbert Slusarek
And here is the proposed fix:
https://lore.kernel.org/netdev/20210619161813.2098382-1-cascardo@canonical.com/T/#u
Regards.
Thadeu Cascardo.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
