Commit ed42989eab57 ("tipc: fix the skb_unshare() in tipc_buf_append()")
replaced skb_unshare() with skb_copy() to not reduce the data reference
counter of the original skb intentionally. This is not the correct
way to handle the cloned skb because it causes memory leak in 2
following cases:
1/
From: Jon Maloy
TIPC reserves 64 service types for current and future internal use.
Therefore, the bind() function is meant to block regular user sockets
from being bound to these values, while it should let through such
bindings from internal users.
However, since we at the design moment saw
Hi Jon,
I have one idea about how to block the vulnerability described below from
happening. Although it's not so elegant, it's quite simple:
As you mentioned below, TIPC_TOP_SRV service is only published in
tipc_topsrv_create_listener () from kernel space. So probably we can change the
code
Commit ed42989eab57 ("fix the skb_unshare() in tipc_buf_append()")
replaced skb_unshare() with skb_copy() to not reduce the data reference
counter of the original skb intentionally. This is not the correct
way to handle the cloned skb because it causes memory leak in 2
following cases:
1/ Sending
Commit ed42989eab57 ("fix the skb_unshare() in tipc_buf_append()")
replaced skb_unshare() with skb_copy() to not reduce the data reference
counter of the original skb intentionally. This is not the correct
way to handle the cloned skb because it causes memory leak in 2
following cases:
1/ Sending
On Mon, Oct 26, 2020 at 5:30 PM Tung Quang Nguyen
wrote:
>
> Hi Xin,
>
> Yes, I know that it should not be a problem if skb_free(NULL) is called.
> But I relied on your analysis for syzbot report:
> "
> in tipc_msg_reassemble():
>
> if ((, ))
> break;
>
Hi Xin,
Yes, I know that it should not be a problem if skb_free(NULL) is called.
But I relied on your analysis for syzbot report:
"
in tipc_msg_reassemble():
if ((, ))
break;
if (!head)
goto error; <--- [1]
}
On Fri, Oct 23, 2020 at 4:20 PM Tung Nguyen
wrote:
>
> Commit ed42989eab57 ("fix the skb_unshare() in tipc_buf_append()")
> replaced skb_unshare() with skb_copy() to not reduce the data reference
> counter of the original skb intentionally. This is not the correct
> way to handle the cloned skb
