linux-kernel - Re: [PATCH] ipv4: Improve martian logs

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: <c269cd25-9e77-4b8c-9cf6-8f2cc86296e7@kernel.org>
Date: Sat, 3 Jan 2026 12:30:08 -0700
From: David Ahern <dsahern@...nel.org>
To: Clara Engler <cve@....cx>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
 pabeni@...hat.com, horms@...nel.org
Subject: Re: [PATCH] ipv4: Improve martian logs

On 1/1/26 5:51 AM, Clara Engler wrote:
> At the current moment, the logs for martian packets are as follows:
> ```
> martian source {DST} from {SRC}, on dev {DEV}
> martian destination {DST} from {SRC}, dev {DEV}
> ```
> 
> These messages feel rather hard to understand in production, especially
> the "martian source" one, mostly because it is grammatically ambitious
> to parse which part is now the source address and which part is the
> destination address.  For example, "{DST}" may there be interpreted as
> the actual source address due to following the word "source", thereby
> implying the actual source address to be the destination one.
> 
> Personally, I discovered this bug while toying around with TUN
> interfaces and using them as a tunnel (receiving packets via a TUN
> interface and sending them over a TCP stream; receiving packets from a
> TCP stream and writing them to a TUN).[^1]
> 
> When these IP addresses contained local IPs (i.e. 10.0.0.0/8 in source
> and destination), everything worked fine.  However, sending them to a
> real routable IP address on the internet led to them being treated as a
> martian packet, obviously.  Using a few sysctl(8) and iptables(8)
> settings[^2] fixed it, but while debugging I found the log message
> starting with "martian source" rather confusing, as I was unsure on
> whether the packet that gets dropped was the packet originating from me
> or the response from the endpoint, as "martian source <ROUTABLE IP>"
> could also be falsely interpreted as the response packet being martian,
> due to the word "source" followed by the routable IP address, implying
> the source address of that packet is set to this IP, as explained above.
> In the end, I had to look into the source code of the kernel on where
> this error message gets generated, which is usually an indicator of
> there being room for improvement with regard to this error message.
> 
> In terms of improvement, this commit changes the error messages for
> martian source and martian destination packets as follows:
> ```
> martian source (src={SRC}, dst={DST}, dev={DEV})
> martian destination (src={SRC}, dst={DST}, dev={DEV})
> ```
> 
> These new wordings leave pretty much no room for ambiguity as all
> parameters are prefixed with a respective key explaining their semantic
> meaning.
> 
> See also the following thread on LKML.[^3]
> 
> [^1]: <https://backreference.org/2010/03/26/tuntap-interface-tutorial>
> [^2]: sysctl net.ipv4.ip_forward=1 && \
>       iptables -A INPUT -i tun0 -j ACCEPT && \
>       iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> [^3]: <https://lore.kernel.org/all/aSd4Xj8rHrh-krjy@4944566b5c925f79/>
> 
> Signed-off-by: Clara Engler <cve@....cx>
> ---
>  net/ipv4/route.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 


Reviewed-by: David Ahern <dsahern@...nel.org>