]> www.infradead.org Git - users/jedix/linux-maple.git/commit
net: mctp: use nlmsg_payload() for netlink message data extraction
authorJeremy Kerr <jk@codeconstruct.com.au>
Wed, 21 May 2025 09:33:36 +0000 (17:33 +0800)
committerPaolo Abeni <pabeni@redhat.com>
Mon, 26 May 2025 15:38:27 +0000 (17:38 +0200)
commit0a9b2c9fd1688c7ecbff0702855577a3f8eef1df
tree5b1752fbf1546169d266098d652dd98f31c5e598
parent31eaaa5cb5e3a11290e037dbe00c90eb9f48b78a
net: mctp: use nlmsg_payload() for netlink message data extraction

Jakub suggests:

> I have a different request :) Matt, once this ends up in net-next
> (end of this week) could you refactor it to use nlmsg_payload() ?
> It doesn't exist in net but this is exactly why it was added.

This refactors the additions to both mctp_dump_addrinfo(), and
mctp_rtm_getneigh() - two cases where we're calling nlh_data() on an
an incoming netlink message, without a prior nlmsg_parse().

For the neigh.c case, we cannot hit the failure where the nlh does not
contain a full ndmsg at present, as the core handler
(net/core/neighbour.c, neigh_get()) has already validated the size
through neigh_valid_req_get(), and would have failed the get operation
before the MCTP hander is called.

However, relying on that is a bit fragile, so apply the nlmsg_payload
refector here too.

Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Link: https://patch.msgid.link/20250521-mctp-nlmsg-payload-v2-1-e85df160c405@codeconstruct.com.au
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
net/mctp/device.c
net/mctp/neigh.c