Callers of ip_srcid_find_id() need to be more careful
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.