Double free in DCCP module causing kernel panic

Bug #1883840 reported by Hadar Manor on 2020-06-17
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Hadar Manor

Bug Description

The problem is when the sock object gets cloned via dccp_create_openreq_child(),
it gives all its attributes to the child sock object, and no reference counter
is taken for the object dccps_hc_tx_ccid.
If one of the sock objects (the parent or the cahild) is closes or disconnected,
it frees the target objects dccps_hc_tx_ccid and provides us a dagling pointer in the other sock object.
This causes an exploitable double free for an object contains function pointers.

We can free dccps_hc_tx_ccid by calling connect(AF_UNSPEC),then spray the heap with other allocations,
then call close() we'll potentially have a RIP control.

This chunk of code is the responsible of freeing dccps_hc_tx_ccid, if called again it will call
ccid_hc_tx_exit() from a freed object

void ccid_hc_tx_delete(struct ccid *ccid, struct sock *sk)
 if (ccid != NULL) {
  if (ccid->ccid_ops->ccid_hc_tx_exit != NULL)
   ccid->ccid_ops->ccid_hc_tx_exit(sk); // <-- Calling a function pointer
  kmem_cache_free(ccid->ccid_ops->ccid_hc_tx_slab, ccid);

disassembly :

(gdb) disas ccid_hc_tx_delete
Dump of assembler code for function ccid_hc_tx_delete:
   0xffffffff81a7a3a0 <+0>: test rdi,rdi
   0xffffffff81a7a3a3 <+3>: je 0xffffffff81a7a3cd <ccid_hc_tx_delete+45>
   0xffffffff81a7a3a5 <+5>: push rbx
   0xffffffff81a7a3a6 <+6>: mov rbx,rdi
   0xffffffff81a7a3a9 <+9>: mov rdi,rsi
   0xffffffff81a7a3ac <+12>: mov rax,QWORD PTR [rbx]

   0xffffffff81a7a3af <+15>: mov rdx,QWORD PTR [rax+0x80] <— rax points to a freed object

   0xffffffff81a7a3b6 <+22>: test rdx,rdx
   0xffffffff81a7a3b9 <+25>: je 0xffffffff81a7a3c0 <ccid_hc_tx_delete+32>

   0xffffffff81a7a3bb <+27>: call rdx // <-- arbitrary call

   0xffffffff81a7a3bd <+29>: mov rax,QWORD PTR [rbx]
   0xffffffff81a7a3c0 <+32>: mov rsi,rbx
   0xffffffff81a7a3c3 <+35>: mov rdi,QWORD PTR [rax+0x18]
   0xffffffff81a7a3c7 <+39>: pop rbx
   0xffffffff81a7a3c8 <+40>: jmp 0xffffffff811fb980 <kmem_cache_free>
   0xffffffff81a7a3cd <+45>: repz ret
End of assembler dump.

CVE References

Hadar Manor (hadarm) wrote :
Changed in linux (Ubuntu):
assignee: nobody → Hadar Manor (hadarm)
summary: - Double free in DCCP module causing kernel panic
+ Double free in DCCP module causing kernel panic
Changed in linux (Ubuntu):
assignee: Hadar Manor (hadarm) → Thadeu Lima de Souza Cascardo (cascardo)
Hadar Manor (hadarm) on 2020-08-31
Changed in linux (Ubuntu):
assignee: Thadeu Lima de Souza Cascardo (cascardo) → Hadar Manor (hadarm)
Hadar Manor (hadarm) wrote :

Hey, is there anything new?

description: updated

Hi, Hadar.

Does the following patch fix the issue from your side?


Hadar Manor (hadarm) wrote :

Hey thank you for fixing!
How can I get CVE on this one?

Thank you Cascardo :)

Seth Arnold (seth-arnold) wrote :

Hello, please use CVE-2020-16119 for this issue. Thanks.

Hadar Manor (hadarm) wrote :

I know the CVE number is reserved for now, there is already a patch - when the cve will be active?
Thank you.

On Wed, Sep 02, 2020 at 01:04:03AM -0000, Hadar Manor wrote:
> I know the CVE number is reserved for now, there is already a patch -
> when the cve will be active?

I can't give a strict timeline for that right now; it depends in part on
upstreak kernel community and in part upon our other work priorities. It's
probably 'weeks' but might happen sooner.


Hadar Manor (hadarm) wrote :

Hey Seth,
thank you for the details
can you inform me when the CVE will be activated and also write my name on it?
Thank you very much!

Hi, Hadar.

Can you let me know if the attribution on this patch is fine for you? We are still not close to disclosure, but I would like to have this patch ready as soon as possible.

Thank you very much.

Hadar Manor (hadarm) wrote :

Hey Cascardo,
The patch is fine for me,
Thank you very much!

Hadar Manor (hadarm) wrote :

is there anything new on the disclosure?
Thank you.

Hi, Hadar. There are plans to get this public by October 13th.


Steve Beattie (sbeattie) wrote :

Hi Hadar,

Specifically, we are proposing 17:00 UTC October 13th, 2020 as a disclosure date; however, we please ask that you delay publishing a PoC exploit for a few days to give people time to apply updates. We will make this bug report public one week after the embargo date, so October 20th, 2020.

Thanks again for the excellent report and your patience!

Hadar Manor (hadarm) wrote :

Could you please can send me a link for the disclosure when it's out?
Thank you!

information type: Private Security → Public Security
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Bug attachments