Project

General

Profile

Actions

Bug #4596

closed

Callers of ip_srcid_find_id() need to be more careful

Added by Dan McDonald over 8 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
networking
Start date:
2014-02-13
Due date:
% Done:

10%

Estimated time:
Difficulty:
Hard
Tags:
Gerrit CR:

Description

I'm attaching a program that, when used with a specific argument, can cause a DEBUG kernel to panic with an ASSERT failure, and on a non-DEBUG kernel, cause at least oddness, and if modified to transmit IPv6 packet, possibly cause v4-mapped addresses to go out on the wire.

The __sin6_src_id field in sockaddr_in6 is used for UDP address reflection. It can also be used to force a source address during connect(3socket) operations.

A user discovered that a program was using uninitialized sockaddr_in6 structures and occasionally, __sin6_src_id would be set to a value that caused the panic on his DEBUG kernel.

. . .

The solution is to have callers of ip_srcid_find_id() using user-supplied input (likely ALL of the callers are in reaction to user-supplied input) reality check the returned IPv6 address against the destination. v4-mapped only goes along with a v4-mapped destination, and v6-only should only go with v6-only. This may involve rearchitecting the function, to return an error (EADDRNOTAVIAIL?) if such a mismatch occurs. There may be some code-cleanup that can occur too, as I see at least one caller where srcid is always set to 0.

NOTE: TO see the srcids, use "mdb -k" and utter ::srcid_status.


Files

sin6_wire.c (1.31 KB) sin6_wire.c Improved bug-tickler, does UDP sendto() or TCP connect(). Dan McDonald, 2014-03-03 10:21 PM

Related issues

Related to illumos gate - Bug #4838: Fix for 4596 has some inverted booleansClosed2014-05-02

Actions
Actions

Also available in: Atom PDF