Bug 95277 - [netinet] [patch] IP Encapsulation mask_match() returns wrong results
Summary: [netinet] [patch] IP Encapsulation mask_match() returns wrong results
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-net (Nobody)
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2006-04-03 19:40 UTC by Qiao Yang
Modified: 2022-10-17 12:36 UTC (History)
1 user (show)

See Also:


Attachments
maskmatch.c (3.19 KB, text/plain)
2006-09-28 18:07 UTC, Bruce M Simpson
no flags Details
maskmatch.diff (1.73 KB, patch)
2006-09-28 18:22 UTC, Bruce M Simpson
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Qiao Yang 2006-04-03 19:40:16 UTC
As documented in the code,
/*
                 * We prioritize the matches by using bit length of the
                 * matches.  mask_match() and user-supplied matching function
                 * should return the bit length of the matches (for example,
                 * if both src/dst are matched for IPv4, 64 should be returned).
                 * 0 or negative return value means "it did not match".
*/

But in mask_match(), it use "struct sockaddr" to do byte-array comparison
when applying the network mask. The problem is that this mask is applied to
the whole 'struct sockaddr' data structure. Because 'struct sockaddr' includes
both sa_len and sa_family, the result match_len will not be 0 even when the
network mask is 0.0.0.0. And, if both src/dst are matched for IPv4, 88 instead
of 64 is returned.

This causes problem for protocols which want to set 0.0.0.0 netmask on the
tunnel end.

Fix: 

When doing byte-array comparison, use sockaddr.sa_data instead of sockaddr.
How-To-Repeat: Just read the code.
Comment 1 Bruce M Simpson 2006-09-28 18:07:34 UTC
I don't quite get this. Test case attached.
Comment 2 Bruce M Simpson 2006-09-28 18:22:46 UTC
I guess a patch for the desired behaviour would look something like this?
More detail needed...
Comment 3 Bruce M Simpson freebsd_committer freebsd_triage 2006-09-28 18:25:33 UTC
State Changed
From-To: open->feedback

Can you confirm the issue still exists in RELENG_6? 
I see no code changes but I can't seem to reproduce it with the 
test case I wrote, and more information would be very welcome!
Comment 4 Bruce M Simpson freebsd_committer freebsd_triage 2006-09-28 18:30:09 UTC
Responsible Changed
From-To: freebsd-bugs->net

over to net for more discussion
Comment 5 John-Mark Gurney freebsd_committer freebsd_triage 2006-10-03 00:14:49 UTC
Responsible Changed
From-To: net->freebsd-net

move w/ the others...
Comment 6 Mark Linimon freebsd_committer freebsd_triage 2008-03-02 02:44:10 UTC
State Changed
From-To: feedback->open

Note that feedback was received some time ago.
Comment 7 Hiren Panchasara freebsd_committer freebsd_triage 2017-01-05 22:07:37 UTC
Provided feedback is missing from the PR. Can someone add that?
Is this still valid?
Comment 8 Andrey V. Elsukov freebsd_committer freebsd_triage 2017-01-06 13:47:30 UTC
As I see, the described problem is still there. But currently there are no consumers of the encap_attach KPI in the tree.
Comment 9 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:41:52 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 10 Graham Perrin freebsd_committer freebsd_triage 2022-10-17 12:36:38 UTC
Keyword: 

    patch
or  patch-ready

– in lieu of summary line prefix: 

    [patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

    <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>