* Daniel Fuchs: > Hi, > > Please find below a fix for: > > 8231260: (dc) DatagramChannel::disconnect changes the port of the > local address to 0 (lnx) > https://bugs.openjdk.java.net/browse/JDK-8231260
I remember looking at this a couple of years ago. I was mostly concerned about the legacy datagram socket back then, where the rebinding can fail as well. Not sure if a bug was field about the behavioral different between the two socket implementations at the time. I'm a bit worried about the first hunk: @@ -873,10 +873,15 @@ synchronized (stateLock) { ensureOpen(); if (state == ST_CONNECTED) throw new AlreadyConnectedException(); + // ensure that the socket is bound + if (localAddress == null) { + bindInternal(null); + } + int n = Net.connect(family, fd, isa.getAddress(), isa.getPort()); if (n <= 0) Doesn't it introduce a race condition where the socket has a port and queue packets, but the kernel will not perform source address checking because it is unconnected? The legacy datagram socket implementation also has logic to deal with packets that arrive after a disconnect (CVE-2014-6512, the explicitFilter stuff). I think DatagramChannelImpl would need something comparable if we want to paper over the kernel behavior. Some background: <https://www.openwall.com/lists/oss-security/2014/10/17/8> <https://www.openwall.com/lists/oss-security/2017/11/06/9> Thanks, Florian