lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fb3980b64d1c827ad59726bb30761d735396e109.1763130571.git.not@dzwdz.net>
Date: Fri, 14 Nov 2025 15:29:30 +0100
From: Jakub Głogowski <not@...dz.net>
To: Alejandro Colomar <alx@...nel.org>
Cc: Jakub Głogowski <not@...dz.net>,
	linux-man@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	Linux API <linux-api@...r.kernel.org>,
	ej@...i.de
Subject: [PATCH 1/2] man/man7/ip.7: Clarify PKTINFO's semantics depending on packet direction

For recvmsg(2), ipi_spec_dst is set by ipv4_pktinfo_prepare() to the
result of fib_compute_sec_dst().  The latter was introduced in
	linux.git 35ebf65e851c6d97 ("ipv4: Create and use fib_compute_spec_dst() helper.").

Quoting its commit message:

> The specific destination is the host we direct unicast replies to.
> Usually this is the original packet source address, but if we are
> responding to a multicast or broadcast packet we have to use something
> different.
>
> Specifically we must use the source address we would use if we were to
> send a packet to the unicast source of the original packet.

Experimentation seems to confirm that behavior.

As for the note about ipi_spec_dst being on a different interface:
- For unicast packets (for which ipi_spec_dst is the original
  destination address), I believe this is trivially true because Linux
  uses the weak host model (unless there's some interaction with
  RTCF_LOCAL that I'm missing).
- For multicast/broadcast packets, fib_compute_sec_dst() only passes the
  original interface to the lookup in the context of L3M.  In
  particular, the original implementation (cited above) set iif and oof
  to 0. Also, citing
	linux.git e7372197e15856ec ("net/ipv4: Set oif in fib_compute_spec_dst"),
  > If the device is not enslaved, oif is still 0 so no affect.

It doesn't seem like using an address specifically from the interface
the packet was received on was ever the intention.  I've also confirmed
this behavior (sending a multicast packet from another machine, whose IP
I've routed to a dummy interface).

I'm focusing on this because that's a misconception I've had before
digging into the code - the sendmsg behavior explained in the same
paragraph made me think ipi_spec_dst was the (primary?) address of
ipi_ifindex.  I think this is worth clarifying.

I've made it explicit that ipi_addr isn't used by sendmsg because that's
another possible misconception.

The (first) extra comma in sendmsg's ipi_spec_dst's description is meant
to emphasize that it's used as the local source address _and_ for the
routing table lookup, as opposed to just affecting the routing table
lookup.
Stylistically it might be a bit weird but idk how to convey this better.

Apart from the cited commits I was referencing the linux-6.17.7 tarball.

__fib_validate_source (and the comment near it) might also be of
interest to people trying to figure out what "specific destinations"
are, exactly.

Signed-off-by: Jakub Głogowski <not@...dz.net>
---
 man/man7/ip.7 | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/man/man7/ip.7 b/man/man7/ip.7
index a92939cd0..a7f118b42 100644
--- a/man/man7/ip.7
+++ b/man/man7/ip.7
@@ -809,12 +809,20 @@ .SS Socket options
 .EE
 .in
 .IP
+When returned by
+.BR recvmsg (2) ,
 .I ipi_ifindex
 is the unique index of the interface the packet was received on.
 .I ipi_spec_dst
-is the local address of the packet and
+is the preferred source address for replies to the given packet, and
 .I ipi_addr
 is the destination address in the packet header.
+These addresses are usually the same,
+but can differ for broadcast or multicast packets.
+Note that, depending on the configured routes,
+.I ipi_spec_dst
+might belong to a different interface from the one that received the packet.
+.IP
 If
 .B IP_PKTINFO
 is passed to
@@ -822,14 +830,16 @@ .SS Socket options
 and
 .\" This field is grossly misnamed
 .I ipi_spec_dst
-is not zero, then it is used as the local source address for the routing
-table lookup and for setting up IP source route options.
+is not zero, then it is used as the local source address, for the routing
+table lookup, and for setting up IP source route options.
 When
 .I ipi_ifindex
 is not zero, the primary local address of the interface specified by the
 index overwrites
 .I ipi_spec_dst
 for the routing table lookup.
+.I ipi_addr
+is ignored.
 .IP
 Not supported for
 .B SOCK_STREAM
-- 
2.47.3


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ