A race condition in the CAN ISOTP networking protocol was discovered which
allows forbidden changing of socket members after binding the socket.

In particular, the lack of locking behavior in isotp_setsockopt() makes it
feasible to assign the flag CAN_ISOTP_SF_BROADCAST to the socket, despite having
previously registered a can receiver. After closing the isotp socket, the can
receiver will still be registered and use-after-free's can be triggered in
isotp_rcv() on the freed isotp_sock structure.
This leads to arbitrary kernel execution by overwriting the sk_error_report()
pointer, which can be misused in order to execute a user-controlled ROP chain to
gain root privileges.

The vulnerability was introduced with the introduction of SF_BROADCAST support
in commit 921ca574cd38 ("can: isotp: add SF_BROADCAST support for functional
addressing") in 5.11-rc1.
In fact, commit 323a391a220c ("can: isotp: isotp_setsockopt():
block setsockopt on bound sockets") did not effectively prevent isotp_setsockopt()
from modifying socket members before isotp_bind().

The requested CVE ID will be revealed along with further exploitation details
as a response to this notice on 13th May of 2021.

Credits: Norbert Slusarek

*** exploit log ***

Adjusted to work with openSUSE Tumbleweed.

noprivs@suse:~/expl> uname -a
Linux suse 5.12.0-1-default #1 SMP Mon Apr 26 04:25:46 UTC 2021 (5d43652) x86_64 x86_64 x86_64 GNU/Linux
noprivs@suse:~/expl> ./lpe
[+] entering setsockopt
[+] entering bind
[+] left bind with ret = 0
[+] left setsockopt with flags = 838
[+] race condition hit, closing and spraying socket
[+] sending msg to run softirq with isotp_rcv()
[+] check sudo su for root rights
noprivs@suse:~/expl> sudo su
suse:/home/noprivs/expl # id
uid=0(root) gid=0(root) groups=0(root)
suse:/home/noprivs/expl # cat /root/check
high school student living in germany looking for an internship in info sec.
if interested please reach out to nslusarek@gmx.net.

Regards,
Norbert Slusarek