I'm still investigating this issue, but it appears to be a socket buffer
corruption after a free inside the linx kernel module on the when
sending/receiving a linx message. The free happens in linx_ioctl_receive. I'll
post more information as I find it. The one thing I would like to do is try
and map the corrupted buffer to some structure (to see what is writing the 02
00 00 00). What structure would this be?
From what I can tell, the corrupted field lies in the sb_buff->cb (control
buffer) which maps to the linx_skb_cb structure. I'm not sure if my dummied up
sk_buff is the right size, but if it is, then the corrupted field seems to be
linx_skb_cb->type being set to LINX_TYPE_REMOTE after the free.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I added some asserts to check if linx_skb_cb->type value matches 0x6b6b6b6b
(fill value after object freed). I then re-ran the test and got the following
assert:
The line of code that trigged this is in af_linx.c:
/* This is so linx_recvmsg() knows if the sender was a local or * remote socket when counting local/remote received bytes. */LINX_ASSERT(cb->type!=0x6b6b6b6b);cb->type=linx_sk(from)->type;
I'm not sure how the message is being freed, but I'm guessing it has something
to do with the message being added to the skb_queue_tail and then we write
into the message...which doesn't make too much sense.
Thoughts? Suggestions?
Thanks in advance,
Drew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm still investigating this issue, but it appears to be a socket buffer
corruption after a free inside the linx kernel module on the when
sending/receiving a linx message. The free happens in linx_ioctl_receive. I'll
post more information as I find it. The one thing I would like to do is try
and map the corrupted buffer to some structure (to see what is writing the 02
00 00 00). What structure would this be?
From what I can tell, the corrupted field lies in the sb_buff->cb (control
buffer) which maps to the linx_skb_cb structure. I'm not sure if my dummied up
sk_buff is the right size, but if it is, then the corrupted field seems to be
linx_skb_cb->type being set to LINX_TYPE_REMOTE after the free.
I added some asserts to check if linx_skb_cb->type value matches 0x6b6b6b6b
(fill value after object freed). I then re-ran the test and got the following
assert:
The line of code that trigged this is in af_linx.c:
I'm not sure how the message is being freed, but I'm guessing it has something
to do with the message being added to the skb_queue_tail and then we write
into the message...which doesn't make too much sense.
Thoughts? Suggestions?
Thanks in advance,
Drew