When trying to bind to an occupied port, Errno 98 (Address already in use) is not reported to the application, making it believe a successful bind was accomplished This issue is first seen in 6.0.16-200.fc36.x86_64, and it previously worked fine in 6.0.15-200.fc36.x86_64 The follow python script will demonstrate the issue import socket port = 23743 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind(('0.0.0.0', port)) print("Asked for port %d, got port %d" % (port, s.getsockname()[1])) assert port == s.getsockname()[1] t = socket.socket(socket.AF_INET, socket.SOCK_STREAM) t.bind(('0.0.0.0', port)) print("Asked for port %d, got port %d" % (port, t.getsockname()[1])) assert port == t.getsockname()[1] maros: ~ $ uname -r 6.0.16-200.fc36.x86_64 maros: ~ $ python socketest.py Asked for port 23743, got port 23743 Asked for port 23743, got port 0 Traceback (most recent call last): File "/home/maros/socketest.py", line 12, in <module> assert port == t.getsockname()[1] AssertionError Expected result, as with the older kernel: Older kernel: [maros@tobfa ~]$ uname -r 6.0.15-200 [maros@tobfa ~]$ python socketest.py Asked for port 23743, got port 23743 Traceback (most recent call last): File "/home/maros/socketest.py", line 10, in <module> t.bind(('0.0.0.0', port)) OSError: [Errno 98] Address already in use The use case for us is that there's an application that needs to communicate using a low (< 1024) source port, and after upgrade to > 6.0.15 this no longer works. The port will be any arbitrary port above 1024.
Hello, being an affected user, I'd like to share my experiences: after hours of debugging I ended up with C code where a `bind` call to an occupied local IP port returns 1 (and errno==0), where a return value of -1 (and errno==98) is expected. My test code is actually a stripped-down version of OpenSSH-8.8p1 server code. The use case here is a pretty common set up: a stock OpenSSH-8.8p1 ssh server running on Fedora 37 is unable to handle multiple X11-forward requests from clients, because with the latest kernel updates applied (6.0.18-300.fc37.x86_64) the ssh server code doesn't detect the situation that the local port 6010 is already in use (by the first connection with X11-forwarding in effect). This is not only a severe problem for the 2nd, 3rd, ... client (because their X11 connection can't be established), but also for the 1st client, because his PTY gets flooded with error messages from completely unrelated ssh connections (from other users) to the same server: each X11 program creates an error message on the 1st user's PTY: `X11 connection rejected because of wrong authentication.`
FYI: the issue seems to be **FIXED** after installing the latest Kernel-Update 6.1.5-200 in Fedora 37.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.