Skip to contentSkip to conversation

What is the role of LIST_POISON1 and LIST_POISON2?

DISCUSSION Navy Cheng 3 participants 4 messages Mar 4, 2016

lore
Share & tools
lore

Navy Cheng

author
#0 lore raw

Hi,

When I read the code of list_del(), I find LIST_POISON1 and LIST_POISON2:

    static inline void list_del(struct list_head *entry)
    {
	__list_del(entry->prev, entry->next);
	entry->next = LIST_POISON1;
	entry->prev = LIST_POISON2;
    }

Why not set entry->next and entry->prev to NULL ?

Thank you!

#1 lore raw
Quoted 4 lines · Navy Cheng

Hi,

When I read the code of list_del(), I find LIST_POISON1 and LIST_POISON2:

Quoted 8 lines
    static inline void list_del(struct list_head *entry)
    {
	__list_del(entry->prev, entry->next);
	entry->next = LIST_POISON1;
	entry->prev = LIST_POISON2;
    }

Why not set entry->next and entry->prev to NULL ?

To more easily detect different classes of list corruption, use-after-free, and other programming errors. If ->next and ->prev are NULL, it may be the result of following a bad pointer. If they're equal to POISON 1 and 2, you're almost certainly looking at a once-valid pointer that is a use-after-free situation. It's easy to end up pointing at a zeroed page. The chances of pointing at some random data that happens to be POISON 1/2 is much lower.

See the code in lib/list_debug.c

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160304/a609403a/attachment.bin

author
#2 lore raw
Quoted 14 lines · Valdis.Kletnieks at vt.edu
Quoted 4 lines · Navy Cheng

Hi,

When I read the code of list_del(), I find LIST_POISON1 and LIST_POISON2:

Quoted 8 lines
    static inline void list_del(struct list_head *entry)
    {
	__list_del(entry->prev, entry->next);
	entry->next = LIST_POISON1;
	entry->prev = LIST_POISON2;
    }

Why not set entry->next and entry->prev to NULL ?

Quoted 9 lines

To more easily detect different classes of list corruption, use-after-free, and other programming errors. If ->next and ->prev are NULL, it may be the result of following a bad pointer. If they're equal to POISON 1 and 2, you're almost certainly looking at a once-valid pointer that is a use-after-free situation. It's easy to end up pointing at a zeroed page. The chances of pointing at some random data that happens to be POISON 1/2 is much lower.

See the code in lib/list_debug.c

Thank you, but I don't quite understand. Could you give an example or tell me some books and documnets about this?

#3 lore raw
Quoted 18 lines · Navy Cheng
Quoted 4 lines · Valdis.Kletnieks at vt.edu
Quoted 3 lines · Navy Cheng

Hi,

When I read the code of list_del(), I find LIST_POISON1 and

LIST_POISON2:

Quoted 11 lines
Quoted 9 lines
    static inline void list_del(struct list_head *entry)
    {
    __list_del(entry->prev, entry->next);
    entry->next = LIST_POISON1;
    entry->prev = LIST_POISON2;
    }

Why not set entry->next and entry->prev to NULL ?

To more easily detect different classes of list corruption,

use-after-free, and

Quoted 14 lines
Quoted 1 line

other programming errors. If ->next and ->prev are NULL, it may be the

result

Quoted 1 line

of following a bad pointer. If they're equal to POISON 1 and 2, you're

almost

Quoted 1 line

certainly looking at a once-valid pointer that is a use-after-free

situation.

Quoted 1 line

It's easy to end up pointing at a zeroed page. The chances of pointing

at

Quoted 4 lines

some random data that happens to be POISON 1/2 is much lower.

See the code in lib/list_debug.c

It's like when you find a pointer to 0xdeadbeef you will know that it is some uninitialized value which is more helpful in debugging. If its a NULL, it will be difficult to know if the pointer is uninitialized.

Quoted 6 lines

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160304/804c60d3/attachment.html