Bug #8719
openeBPF/XDP load fails on kernel ≥ 5.11 when CAP_SYS_RESOURCE is not available but it should not be necessary
Description
`EBPFLoadFile()` unconditionally calls `setrlimit(RLIMIT_MEMLOCK, RLIM_INFINITY)` and treats any failure as fatal (SCLogError + return -1), aborting the eBPF/XDP load.
Since Linux kernel 5.11, BPF map memory is memcg-accounted and is no longer charged against RLIMIT_MEMLOCK (see https://lwn.net/Articles/829307/), so raising the limit is unnecessary on those kernels. The setrlimit call still requires CAP_SYS_RESOURCE. When Suricata runs with dropped/restricted capabilities (i.e. without CAP_SYS_RESOURCE, case of), the call fails with EPERM and eBPF/XDP loading is aborted entirely — even though on a ≥ 5.11 kernel the memlock limit is irrelevant.
AB Updated by Amir Boussejra 1 day ago
- Effort set to low
LS Updated by Lukas Sismis about 22 hours ago
- Status changed from New to Triaged
- Assignee set to OISF Dev
- Target version changed from TBD to 9.0.0-beta1
- Affected Versions 7.0.15 added
This report could be improved by delivering the real reproducer, e.g. by running this SV test suite https://github.com/OISF/suricata-verify/pull/3209/changes in a Docker image that runs on 5.11+ kernel. The suggested SV test runs on https://github.com/OISF/suricata/pull/15774/changes#diff-a76cf7978f0a981f911e8d68d2351a72a268977304612226433df4fb8203b06fR2899
So if I understand your report correctly, you don't need to change/add SV test, just specify "SV_BRANCH=OISF/suricata-verify#3209" in the PR comment with the updated GitHub Action runner as the https://github.com/OISF/suricata/pull/15774 does.
If confirmed, we can request backport tickets.
LS Updated by Lukas Sismis about 22 hours ago
- Status changed from Triaged to In Review