]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
libbpf: Use dynamically allocated buffer when receiving netlink messages
authorToke Høiland-Jørgensen <toke@redhat.com>
Fri, 11 Feb 2022 23:48:19 +0000 (00:48 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 8 Apr 2022 11:58:06 +0000 (13:58 +0200)
commitdc69beab5b7baa106d8a195d2c690f7970a81eb5
treedffa94fcf645fbb1eeada3590e4a3fc39ef7044e
parent7416cbe41329eee689411edfc028fb8d00c7a8f2
libbpf: Use dynamically allocated buffer when receiving netlink messages

[ Upstream commit 9c3de619e13ee6693ec5ac74f50b7aa89056a70e ]

When receiving netlink messages, libbpf was using a statically allocated
stack buffer of 4k bytes. This happened to work fine on systems with a 4k
page size, but on systems with larger page sizes it can lead to truncated
messages. The user-visible impact of this was that libbpf would insist no
XDP program was attached to some interfaces because that bit of the netlink
message got chopped off.

Fix this by switching to a dynamically allocated buffer; we borrow the
approach from iproute2 of using recvmsg() with MSG_PEEK|MSG_TRUNC to get
the actual size of the pending message before receiving it, adjusting the
buffer as necessary. While we're at it, also add retries on interrupted
system calls around the recvmsg() call.

v2:
  - Move peek logic to libbpf_netlink_recv(), don't double free on ENOMEM.

Fixes: 8bbb77b7c7a2 ("libbpf: Add various netlink helpers")
Reported-by: Zhiqian Guan <zhguan@redhat.com>
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/bpf/20220211234819.612288-1-toke@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
tools/lib/bpf/netlink.c