Noticed that call to bpf_sysctl_set_new_value doesn't change final value
of the parameter, when called from cgroup/syscall bpf handler. No error
thrown in this case, new value is simply ignored and original value, sent
to sysctl, is set. Example (see test added to this change for BPF handler
logic):
sysctl -w net.ipv4.ip_local_reserved_ports = 11111
... cgroup/syscal handler call bpf_sysctl_set_new_value and set 22222
sysctl net.ipv4.ip_local_reserved_ports
... returns 11111
On investigation I found 2 things that needs to be changed:
* return value check
* new_len provided by bpf back to sysctl. proc_sys_call_handler expects
this value NOT to include \0 symbol, e.g. if user do
```
open("/proc/sys/net/ipv4/ip_local_reserved_ports", ...)
write(fd, "11111", sizeof("22222"))
```
or `echo -n "11111" > /proc/sys/net/ipv4/ip_local_reserved_ports`
or `sysctl -w net.ipv4.ip_local_reserved_ports=11111
proc_sys_call_handler receives count equal to `5`. To make it consistent
with bpf_sysctl_set_new_value, this change also adjust `new_len` with
`-1`, if `\0` passed as last character. Alternatively, using
`sizeof("11111") - 1` in BPF handler should work, but it might not be
obvious and spark confusion. Note: if incorrect count is used, sysctl
returns EINVAL to the user.
Raman Shukhau (1):
Fix for bpf_sysctl_set_new_value
kernel/bpf/cgroup.c | 7 ++-
.../bpf/progs/test_sysctl_overwrite.c | 47 +++++++++++++++++++
tools/testing/selftests/bpf/test_sysctl.c | 35 +++++++++++++-
3 files changed, 85 insertions(+), 4 deletions(-)
create mode 100644 tools/testing/selftests/bpf/progs/test_sysctl_overwrite.c
--
2.43.0
