All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@nvidia.com>
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
	edumazet@kernel.org, dsahern@kernel.org, horms@kernel.org,
	yoshfuji@linux-ipv6.org, Ido Schimmel <idosch@nvidia.com>
Subject: [PATCH net 0/2] ipmr, ip6mr: Fix several info leaks
Date: Sun, 25 Oct 2026 09:17:27 +0200	[thread overview]
Message-ID: <20261025071729.34967-1-idosch@nvidia.com> (raw)

ip{,6}mr_cache_report() copy the IP header of a packet that triggered an
upcall to a report packet that is delivered to user space. The header
is not always fully initialized or present, resulting in info leaks
flagged by KMSAN.

Patch 1 fixes an info leak in the RTM_GETROUTE path, caused by the fact
that ipmr_get_route() does not fully initialize the IP header of the
packet that it creates. IPv6 does not suffer from this problem.

Patch 2 fixes info leaks triggered by packets injected into pim{,6}reg
devices via AF_PACKET sockets. The kernel does not validate that these
are IP packets that carry an IP header before calling
ip{,6}mr_cache_report().

Both issues were reported by Sashiko and reproduced by me. See KMSAN
traces in the commit messages.

As far as I can tell, all other callers call these functions from the IP
input / output paths and therefore provide a valid IP packet, with the
exception of ip6mr_get_route() which fully initializes the header of the
packet it creates.

Ido Schimmel (2):
  ipmr: fully initialize the synthetic IP header in ipmr_get_route()
  ipmr, ip6mr: validate packets injected into the register vif on xmit

 net/ipv4/ipmr.c  | 7 +++++++
 net/ipv6/ip6mr.c | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

-- 
2.56.0


             reply	other threads:[~2026-10-25  7:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-25  7:17 Ido Schimmel [this message]
2026-10-25  7:17 ` [PATCH net 1/2] ipmr: fully initialize the synthetic IP header in ipmr_get_route() Ido Schimmel
2026-10-25 10:50   ` Eric Dumazet
2026-10-25  7:17 ` [PATCH net 2/2] ipmr, ip6mr: validate packets injected into the register vif on xmit Ido Schimmel
2026-10-25 10:52   ` Eric Dumazet
2026-10-26 23:39   ` Jakub Kicinski
2026-10-26  5:59 ` [PATCH net 0/2] ipmr, ip6mr: Fix several info leaks Hangbin Liu
2026-10-26 23:50 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261025071729.34967-1-idosch@nvidia.com \
    --to=idosch@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@kernel.org \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.