From: Stephen Hemminger <stephen@networkplumber.org>
To: netdev@vger.kernel.org
Cc: dsahern@kernel.org, Stephen Hemminger <stephen@networkplumber.org>
Subject: [PATCH iproute2 0/5] netlink receive path hardening
Date: Sun, 8 Nov 2026 17:43:57 -0800 [thread overview]
Message-ID: <20261109014434.115922-1-stephen@networkplumber.org> (raw)
Six scanner reports all landed on the same code, so they are better
fixed together than one at a time. The time() seeding was parallel
discovery: Florian reported it on netdev independently of the two
scanner findings that flagged it.
The common thread is that iproute2 trusted whatever came back from its
own socket. The sender went unchecked until after the framing checks,
and in the ss -D case until after the datagram had been written to the
dump file. The framing walk assumed every message in a datagram is
padded. Any process with CAP_NET_ADMIN over the namespace could use
that to inject events into a monitor, or to keep a dump from ever
completing.
One behavior change: paths that used to exit(1) on a short or malformed
datagram now skip it and carry on, since a datagram from a non-kernel
sender is no reason to abort.
Note: rdma monitor is not fixed by these changes. It opens its socket with a
bare mnl_socket_open(), so the connect() does not reach it.
Worth exercising:
- ip monitor all, ip -r monitor, devlink monitor, rdma monitor.
- ss -D dump recording, and replay with ss -F.
- ss -E, which sets local.nl_pid = 0 and dump = 0 to match multicast
notifications. Should be unaffected: it relies on the
nlmsg_pid/nlmsg_seq comparison, unchanged here, and the
nladdr.nl_pid requirement it already met is now enforced earlier in
rtnl_recvmsg().
- rdma stat and rdma dev, now going through mnlu_socket_recvfrom()
and mnlu_next_seq().
Stephen Hemminger (5):
netlink: use a counter for sequence numbers
netlink: ignore messages not sent by the kernel
netlink: connect sockets to the kernel
netlink: handle unpadded last message in receive loops
libnetlink: do not read past datagram when recording dump
include/mnl_utils.h | 2 +
lib/libnetlink.c | 131 +++++++++++++++++++++-----------------------
lib/mnl_utils.c | 54 +++++++++++++++++-
rdma/stat.c | 2 +-
rdma/utils.c | 2 +-
5 files changed, 117 insertions(+), 74 deletions(-)
--
2.53.0
next reply other threads:[~2026-11-09 1:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 1:43 Stephen Hemminger [this message]
2026-11-09 1:43 ` [PATCH iproute2 1/5] netlink: use a counter for sequence numbers Stephen Hemminger
2026-11-09 1:43 ` [PATCH iproute2 2/5] netlink: ignore messages not sent by the kernel Stephen Hemminger
2026-11-09 1:44 ` [PATCH iproute2 3/5] netlink: connect sockets to " Stephen Hemminger
2026-11-09 1:44 ` [PATCH iproute2 4/5] netlink: handle unpadded last message in receive loops Stephen Hemminger
2026-11-09 1:44 ` [PATCH iproute2 5/5] libnetlink: do not read past datagram when recording dump Stephen Hemminger
2026-11-11 17:30 ` [PATCH iproute2 0/5] netlink receive path hardening 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=20261109014434.115922-1-stephen@networkplumber.org \
--to=stephen@networkplumber.org \
--cc=dsahern@kernel.org \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox