From: Simon Horman <horms@kernel.org>
To: Matt Johnston <matt@codeconstruct.com.au>
Cc: Jeremy Kerr <jk@codeconstruct.com.au>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org,
syzbot+e76d52dadc089b9d197f@syzkaller.appspotmail.com,
syzbot+1065a199625a388fce60@syzkaller.appspotmail.com
Subject: Re: [PATCH net] net: mctp: Don't access ifa_index when missing
Date: Tue, 6 May 2025 17:07:53 +0100 [thread overview]
Message-ID: <20250506160753.GU3339421@horms.kernel.org> (raw)
In-Reply-To: <20250505-mctp-addr-dump-v1-1-a997013f99b8@codeconstruct.com.au>
On Mon, May 05, 2025 at 05:05:12PM +0800, Matt Johnston wrote:
> In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but
> only when the struct ifaddrmsg is provided. Otherwise it will be
> comparing to uninitialised memory - reproducible in the syzkaller case from
> dhcpd, or busybox "ip addr show".
>
> The kernel MCTP implementation has always filtered by ifa_index, so
> existing userspace programs expecting to dump MCTP addresses must
> already be passing a valid ifa_index value (either 0 or a real index).
>
> BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128
> mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128
> rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380
> rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824
> netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309
>
> Fixes: 583be982d934 ("mctp: Add device handling and netlink interface")
> Reported-by: syzbot+e76d52dadc089b9d197f@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/68135815.050a0220.3a872c.000e.GAE@google.com/
> Reported-by: syzbot+1065a199625a388fce60@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/681357d6.050a0220.14dd7d.000d.GAE@google.com/
> Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
Thanks Matt,
FWIIW, this looks good to me.
Reviewed-by: Simon Horman <horms@kernel.org>
> ---
> net/mctp/device.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/net/mctp/device.c b/net/mctp/device.c
> index 8e0724c56723de328592bfe5c6fc8085cd3102fe..7780acdb99dedca1cd6a17e4d6bf917c7f7f370f 100644
> --- a/net/mctp/device.c
> +++ b/net/mctp/device.c
> @@ -117,11 +117,17 @@ static int mctp_dump_addrinfo(struct sk_buff *skb, struct netlink_callback *cb)
> struct net_device *dev;
> struct ifaddrmsg *hdr;
> struct mctp_dev *mdev;
> - int ifindex, rc;
> + int ifindex = 0, rc;
>
> - hdr = nlmsg_data(cb->nlh);
> - // filter by ifindex if requested
> - ifindex = hdr->ifa_index;
> + /* Filter by ifindex if a header is provided */
> + if (cb->nlh->nlmsg_len >= nlmsg_msg_size(sizeof(*hdr))) {
> + hdr = nlmsg_data(cb->nlh);
FWIIW, I think the scope of the declaration of hdr can be reduced to this block.
(Less positive ease, so to speak.)
> + /* Userspace programs providing AF_MCTP must be expecting ifa_index filter
> + * behaviour, as will those setting strict_check.
> + */
> + if (hdr->ifa_family == AF_MCTP || cb->strict_check)
> + ifindex = hdr->ifa_index;
> + }
>
> rcu_read_lock();
> for_each_netdev_dump(net, dev, mcb->ifindex) {
>
> ---
> base-commit: ebd297a2affadb6f6f4d2e5d975c1eda18ac762d
> change-id: 20250505-mctp-addr-dump-673e0fdc7894
>
> Best regards,
> --
> Matt Johnston <matt@codeconstruct.com.au>
>
next prev parent reply other threads:[~2025-05-06 16:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-05 9:05 [PATCH net] net: mctp: Don't access ifa_index when missing Matt Johnston
2025-05-06 16:07 ` Simon Horman [this message]
2025-05-07 0:58 ` Jakub Kicinski
2025-05-08 17:10 ` Simon Horman
2025-05-07 1:06 ` Jakub Kicinski
2025-05-07 1:24 ` Matt Johnston
2025-05-07 1:41 ` Jakub Kicinski
2025-05-07 2:13 ` Matt Johnston
2025-05-07 2:20 ` Jakub Kicinski
2025-05-07 3:48 ` Matt Johnston
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=20250506160753.GU3339421@horms.kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jk@codeconstruct.com.au \
--cc=kuba@kernel.org \
--cc=matt@codeconstruct.com.au \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=syzbot+1065a199625a388fce60@syzkaller.appspotmail.com \
--cc=syzbot+e76d52dadc089b9d197f@syzkaller.appspotmail.com \
/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.