On Tue, Jun 11, 2019 at 2:46 AM Zhongjie Wang wrote:
>
> Hi Neal,
>
> Thanks for your valuable feedback! Yes, I think you are right.
> It seems not a problem if tp->urg_data and tp->urg_seq are used together.
> From our test results, we can only see there are some paths requiring
> specific initia
Hi Neal,
Thanks for your valuable feedback! Yes, I think you are right.
It seems not a problem if tp->urg_data and tp->urg_seq are used together.
>From our test results, we can only see there are some paths requiring
specific initial sequence number to reach.
But as you said, it would not cause a
On Mon, Jun 10, 2019 at 7:48 PM Zhongjie Wang wrote:
>
> Hi Neal,
>
> Thanks for your reply. Sorry, I made a mistake in my previous email.
> After I double checked the source code, I think it should be tp->urg_seq,
> which is used before assignment, instead of tp->copied_seq.
> Still in the same i
Hi Neal,
Thanks for your reply. Sorry, I made a mistake in my previous email.
After I double checked the source code, I think it should be tp->urg_seq,
which is used before assignment, instead of tp->copied_seq.
Still in the same if-statement:
5189 if (tp->urg_seq == tp->copied_seq && tp->urg
On Sun, Jun 9, 2019 at 11:12 PM Zhongjie Wang wrote:
...
> It compares tp->copied_seq with tcp->rcv_nxt.
> However, tp->copied_seq is only assigned to an appropriate sequence number
> when
> it copies data to user space. So here tp->copied_seq could be equal to 0,
> which is its initial value, if
Hi all,
We are a group of researchers at UC Riverside. We recently discovered
some weird case
in the TCP code in which the tp->copied_seq variable is used before
assignment to an
appropriate TCP sequence number. It's discovered with our symbolic
execution tool,
so we'd like to seek confirmation of
