netdev - A question about inet_csk_bind

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Fri, 30 Mar 2018 19:39:46 +0800
From:   martin zhang <martinbj2008@...il.com>
To:     davem@...emloft.net, Eric Dumazet <edumazet@...gle.com>
Cc:     netdev@...r.kernel.org
Subject: A question about inet_csk_bind_conflict

HI all,

I have a question about tcp bind check function:inet_csk_bind_conflict.

My case:

192.168.56.101:37818    ==> 192.168.56.193:22
On host A (tcp client: 192.168.56.101), there is  a tcp connection to
server B(192.168.56.193, tcp server).

I want run a tcp server on A, and listen/bind tcp port 37818, but it failed.
I check the kernel source and found it is stopped by inet_csk_bind_conflict.

I think in this case, it should success.
Because,
1. when a tcp packet arrives network stack, we firstly look the
established/timewait socket,
and then search for listen socket.
2. peer side(192.168.56.193:22), is a tcp server. It will never
connect to192.168.56.101:37818, with 192.168.56.193:22.

I don’t  understand why the kernel fail at inet_csk_bind_conflict,
I wonder if I ignore some case or  it is a bug?

Thanks!

Martin