Re: CVE-2021-3609: Race condition in net/can/bcm.c leads to local privilege escalation

                							

                <!--X-Body-Begin-->
<!--X-User-Header-->

oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->

By Date

By Thread

</form>

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
Re: CVE-2021-3609: Race condition in net/can/bcm.c leads to local privilege escalation

<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->

From: Thadeu Lima de Souza Cascardo &lt;cascardo () canonical com&gt;

Date: Sat, 19 Jun 2021 13:23:24 -0300

<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->

<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
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() -&gt; bcm_release() on socket 1 to free struct bcm_op and struct bcm_sock

=&gt; 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 &gt;= 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.

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->

<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->

By Date

By Thread

Current thread:

CVE-2021-3609: Race condition in net/can/bcm.c leads to local privilege escalation Norbert Slusarek (Jun 19)

Re: CVE-2021-3609: Race condition in net/can/bcm.c leads to local privilege escalation Thadeu Lima de Souza Cascardo (Jun 19)

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->