Page MenuHomeFreeBSD

netinet: Disallow connections to INADDR_ANY
AcceptedPublic

Authored by emaste on Nov 25 2024, 7:00 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Apr 21, 3:07 AM
Unknown Object (File)
Mon, Apr 21, 3:00 AM
Unknown Object (File)
Mon, Apr 21, 1:25 AM
Unknown Object (File)
Mon, Apr 21, 12:39 AM
Unknown Object (File)
Mon, Apr 21, 12:13 AM
Unknown Object (File)
Mar 10 2025, 2:51 PM
Unknown Object (File)
Mar 1 2025, 12:15 AM
Unknown Object (File)
Feb 6 2025, 3:47 PM

Details

Reviewers
markj
jhb
zlei
Summary

Previously connect() or sendto() to INADDR_ANY reached some socket bound to some host interface address. Although this was intentional it was an artifact of a different era, and is not desirable now.

In 417b35a97b7669eb0bf417b43e97cccbedbce6f9 @markj added support to disallow connect() to INADDR_ANY. Take the next logical step and disable it by default.

[We can do a call for testing on -current first if desired. I'm certain that all potential fallout will not be found by such a request, though.]

Relnotes: Yes
PR: 280705

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

[We can do a call for testing on -current first if desired. I'm certain that all potential fallout will not be found by such a request, though.]

It might be worth giving a heads-up anyway, just so people have a hint if something stops working.

This revision is now accepted and ready to land.Nov 25 2024, 7:30 PM

It might be worth giving a heads-up anyway, just so people have a hint if something stops working.

Yeah, at least a post to -net and -current stating that the default changed, ask people to test if possible but at least be on the lookout for new misbehaviour, and advice on setting the sysctl to revert if necessary.

Does this need an entry in RELNOTES as a followup commit perhaps?

Does this need an entry in RELNOTES as a followup commit perhaps?

It will need a release note, indeed. We have at least two ways that can happen today -- as a result of Relnotes: Yes and by adding to RELNOTES. I believe RELNOTES was originally introduced to capture release notes where Relnotes: Yes was forgotten. It is probably better to capture the important aspect of the change at the time it happens and by the author of the change though, and perhaps we should deprecate Relnotes: Yes

Does this need an entry in RELNOTES as a followup commit perhaps?

It will need a release note, indeed. We have at least two ways that can happen today -- as a result of Relnotes: Yes and by adding to RELNOTES. I believe RELNOTES was originally introduced to capture release notes where Relnotes: Yes was forgotten. It is probably better to capture the important aspect of the change at the time it happens and by the author of the change though, and perhaps we should deprecate Relnotes: Yes

I think of Relnotes: yes as being a quick way to signal that someone _else_ should write a release note, whereas adding an entry to RELNOTES means that the release engineering team can just use that language without rewriting it. For trivial things like a version bump that is obvious from the commit log, I think Relnotes: yes is ok, but for anything non-trivial I think RELNOTES is better and we should encourage it.