SSD Advisory – Linux AF_LLC Double Free

Credit to Author: SSD / Noam Rathaus| Date: Mon, 30 Apr 2018 13:05:13 +0000

Want to get paid for a vulnerability similar to this one?
Contact us at: sxsxdx@xbxexyxoxnxdxsxexcxuxrxixtxy.xcom
See our full scope at:

Vulnerability Summary
A use after free vulnerability in AF_LLC allows local attackers to control the flow of code that the kernel executes, allowing them to cause it to run arbitrary code and gain elevated privileges.

Vendor Response
The vulnerability was reported to the Kernel Security, which asked us to contact the netdev team. A patch was provided by the netdev team, on the 27th of March, and was later integrated into the main code of Linux (we are not certain when).

Attempts to recontact the netdev and understand more on the timeline, went unanswered.

We know that the patch has been introduced as part of:

An independent security researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.

Affected systems
The oldest known version to be affected Linux version, the patch has been introduced as part of 4.17-rc2.

Vulnerability Details
LLC sockets can only be created with CAP_NET_RAW capability. Setsockopt() with SO_BINDTODEVICE is necessary to setup sk->sk_bound_dev_if so that bind() won’t fail as well as llc_ui_sendmsg() when checking that llc->addr is initialized.

Then after connecting and sending a message, the code leads to llc_build_and_send_pkt.

The error can be spotted in llc_conn_state_process():

The end of the function see 2 consecutive free on the skb which causes a UAF first followed by a double free as seen in the crash log:

Exploiting the double free on the struct sk_buff itself is not easy due to that fact that it belongs to its own slab. However, a sk_buff has a kmalloc-ed buffer which is allocated and deallocated side by side with it (cf. It’s kind of similar to 2 consecutive double free.

We want to target the 2nd free to free any other object with function pointers (in the general kmalloc) so that we can abuse the crafted UAF. A good target could be to free a skb’s buffer and control the destructor_arg in skb_shared_info just like the writeup in the above link.

Proof of Concept

This will result in a (similar to this) crash log:

Print Friendly, PDF & Email