Searching in a lock-free ordered single-linked list
Lockless list not threadsafe
I was able to break your list with a simple program:
LF_List list = {0};

void *threadFunc(void *arg)
{
    uint64_t key = (uintptr_t) arg;
    int i;

    for (i=0;i&lt;100000;i++) {
        lf_list_put_if_absent(&amp;list, key, (void *) 1);
        if (lf_list_remove(&amp;list, key) == 0) {
            printf(&quot;ERROR\n&quot;);
            exit(1);
        }
    }
    return NULL;
}

int main(void)
{
    pthread_t t1, t2;
    pthread_create(&amp;t1, 0, threadFunc, (void *) 9);
    pthread_create(&amp;t2, 0, threadFunc, (void *) 8);
    pthread_join(t1, NULL);
    pthread_join(t2, NULL);
}

When I ran this program, one of three things happened:

The program terminated (no errors).
The program printed ERROR, meaning that something went wrong with a put or remove.
The program never terminated, indicating a cycle in the list was created.

I was also able to cause a segmentation violation by modifying lf_list_remove() to write 0xffffffff to the next pointer of a node just before freeing it:
    if (CAS(prev, cur, PTR_OF(cur)-&gt;next) == cur) {
        // Once a pointer is freed, its memory could be trashed.
        // Simulate this by writing an invalid address to cur-&gt;next.
        PTR_OF(cur)-&gt;next = 0xffffffff;
        free(PTR_OF(cur));
        INCR(&amp;table-&gt;size, -1);
        return 1;
    } else {
        continue;
    }

I was also able to cause the program to crash by specifically adding some strategic sleep() calls to cause two threads to perform a specific sequence of events, but that code is too lengthy to list here unless you really want to see it.
Basically, what it all boils down to is that when one thread is freeing a node, the other thread can access the freed node because there is nothing to stop it from doing so.  The original code in the research paper used marking bits to prevent this from happening, but those marking bits have been removed from this implementation.