Some calls were already using it, some were not, but fix the remaining
ones.
Without this flag, the file descriptor would to the child process after
fork/exec.
Signed-off-by: Andrey Smirnov <andrey.smirnov@siderolabs.com>
For 4.20 and newer kernels VethPeerIndex() causes a stack corruption as
the kernel is copying more data to golang user space than originally
expected. This is due to a recent kernel commit where it extends veth
driver's ethtool stats for XDP:
https://git.kernel.org/torvalds/c/d397b9682c1c808344dd93b43de8750fa4d9f581
The VethPeerIndex()'s logic is utterly wrong to assume ethtool stats are
never extended in the driver. Unfortunately there is no other way around
in golang than to add serialize/deserialize helpers to have a dynamically
sized ethtoolStats with a uint64 data array that has the size of the previous
result from the ETHTOOL_GSSET_INFO query. This ensures we don't run into
a buffer overflow triggered by kernel's copy_to_user() in ETHTOOL_GSTATS
query (ethtool_get_stats() in kernel). Now, for the deserialize operation
we really only care about the peer's ifindex which is always stored in
the first uint64.
Fixes: 54ad9e3a4c ("Two new functions: LinkSetBondSlave and VethPeerIndex")
Reported-by: Jean Raby <jean@raby.sh>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: phob0s <git@phob0s.pl>
It's not needed for retrieving the veth peer ifindex, and we already
get the set count via earlier ETHTOOL_GSSET_INFO call. Both are copying
veth_get_sset_count() up to user space in veth case (which is the only
user of this anyway).
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
