diff options
| author | Jeremy Kerr <[email protected]> | 2025-05-21 09:33:36 +0000 |
|---|---|---|
| committer | Paolo Abeni <[email protected]> | 2025-05-26 15:38:27 +0000 |
| commit | 0a9b2c9fd1688c7ecbff0702855577a3f8eef1df (patch) | |
| tree | 5b1752fbf1546169d266098d652dd98f31c5e598 /net/core/dev_api.c | |
| parent | Merge branch 'add-the-capability-to-consume-sram-for-hwfd-descriptor-queue-in... (diff) | |
| download | kernel-0a9b2c9fd1688c7ecbff0702855577a3f8eef1df.tar.gz kernel-0a9b2c9fd1688c7ecbff0702855577a3f8eef1df.zip | |
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 <[email protected]>
Signed-off-by: Jeremy Kerr <[email protected]>
Link: https://patch.msgid.link/20250521-mctp-nlmsg-payload-v2-1-e85df160c405@codeconstruct.com.au
Signed-off-by: Paolo Abeni <[email protected]>
Diffstat (limited to 'net/core/dev_api.c')
0 files changed, 0 insertions, 0 deletions
