UAF due to using hlist_add_behind() without checking.

There is a pair locker(mutex_lock) at delete_note(), but isn’t at edit_note_time().

And it doesn’t check the flag before hlist_add_behind() in insert_note().

    for(;;) {        /* add before a larger epoch */        iter = hlist_entry(node, struct note_t, next);        if (iter->epoch > epoch) {            hlist_add_before(&(note->next), node);            flag = true;            break;        }        if (node->next == NULL)            break;        node = node->next;    }    /* at behind the last node */    // if (!flag)  <-- patch...	// it can lead to hlist broken.    hlist_add_behind(&(note->next), node);

Exploitation:

1. UaF 

　　First we could free arbitrary object (eg. tty_struct) via any vulnerabilities,
re-allocate fake object with evil functions or rop gadgets.
Finally we can call related function in user mode.

2. kernel info leak

　　should use the kzalloc() instead of kmalloc()

0ctf 2017 kernel pwn knote write up