Bug 2159802 - Kernel 6.0.16 and 6.0.18 don't reject bind() on a duplicate localhost TCP port under some situations
Summary: Kernel 6.0.16 and 6.0.18 don't reject bind() on a duplicate localhost TCP por...
Keywords:
Status: CLOSED DUPLICATE of bug 2159066
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 37
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-01-10 19:04 UTC by Chris Siebenmann
Modified: 2023-01-12 15:48 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-01-12 15:48:35 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
dmesg.txt from 6.0.16 on a libvirt VM showing this problem (63.60 KB, text/plain)
2023-01-10 19:04 UTC, Chris Siebenmann
no flags Details

Description Chris Siebenmann 2023-01-10 19:04:38 UTC
Created attachment 1937150 [details]
dmesg.txt from 6.0.16 on a libvirt VM showing this problem

1. Please describe the problem:
Starting in 6.0.16, calls to bind() on a duplicate port on at least localhost don't fail. I first noticed this issue when the Go test suite began failing on a TCP listen test, where it expects such a duplicate bind() to fail.

2. What is the Version-Release number of the kernel:
6.0.16-300.fc37.x86_64 and 6.0.18-300.fc37.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
Yes, this worked in 6.0.15 and before.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

In Python:
>>> from socket import *
>>> s1 = socket(AF_INET, SOCK_STREAM)
>>> s2 = socket(AF_INET, SOCK_STREAM)
>>> s1.bind(('127.0.0.1', 0))
>>> # Reuse same assigned port
>>> s2.bind(('127.0.0.1', s1.getsockname()[1]))
>>> s1.getsockname()
('127.0.0.1', 36483)
>>> s2.getsockname()
('0.0.0.0', 0)

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:
This doesn't occur in the latest Rawhide, which is 6.2.0-0.rc2.20230105git41c03ba9beea.20.fc38.x86_64 as I write this. Running with that kernel, the last step in the Python reproducer gets the expected error:

>>> s2.bind(('127.0.0.1', s1.getsockname()[1]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 98] Address already in use


6. Are you running any modules that not shipped with directly Fedora's kernel?:
This reproduces on a Fedora 37 virtual machine with only standard modules. My normal kernels use OpenZFS as well.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

Comment 1 Ben Cotton 2023-01-12 14:47:21 UTC
According to a post on the devel list[1], this is fixed in 6.1.4, which is available in koji[2]. I'm setting this to POST for now until an update is created in Bodhi.

[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7XMMKEIXMS4NQ5BSNK4KKUICKAJD3Y2E/
[2] https://koji.fedoraproject.org/koji/buildinfo?buildID=2107960

Comment 2 Chris Siebenmann 2023-01-12 15:27:14 UTC
In addition, I (the reporter) think this is a duplicate of bug #2159066 (pointed out to me elsewhere), so possibly things should be consolidated there.

Comment 3 Ben Cotton 2023-01-12 15:48:35 UTC

*** This bug has been marked as a duplicate of bug 2159066 ***


Note You need to log in before you can comment on or make changes to this bug.