-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent use of get_seccomp_filter vs. __put_seccomp_filter #338
Comments
Alternatively, since We could also have our own implementation of |
I think the saturation should produce warnings in kernel messages. Just need to trigger over 2 billion credentials validations in one task with seccomp. |
Hm... I think you are correct @solardiz. We have problems with So we would need to carry an own definition of it to be able to implement the refcount logic. Nevertheless, we already do something similar for few other structures so maybe it's OKish... @solardiz what do you think? |
We only need the
prior to 2020, it was called
and it was this way since 2017:
The 2017 commit was a type change:
going even further back, we had since 2012:
which covers all of our supported kernel versions. So we're good in terms of this field's placement, but ideally we'll need to use the right type and inc/dec macros to match the 2017 change. In fact, if we try to use typedef struct refcount_struct {
atomic_t refs;
} refcount_t; So defining and using our own struct with just the first field feels low risk for our supported kernels so far. We may. |
What about keeping the call to |
Sounds reasonable to me. |
Starting from kernel 5.9+ function 'put_seccomp_filter' has been inlined and unavailble for hooking. However, internal not-inline function was used to mitigate the problem. Unfortunately, there is no equivalent counter-part function for new hook and the old one looks incompatible which we overlooked. This patch is switching the logic for kernels 5.9+ to custom implementation of refcount logic and it should address the issue reported as lkrg-org#338
While reviewing the kernel's seccomp filter refcount logic, I notice that there can be multiple filters on a task, yet we're currently monitoring just one of them, right? We could want to track this as a separate issue to fix (monitor all of them) or maybe this is a reason for us to drop this feature entirely until we're ready to reimplement it correctly. As it currently is, it may be of little value. |
Starting from kernel 5.9+ function 'put_seccomp_filter' has been inlined and unavailble for hooking. However, internal not-inline function was used to mitigate the problem. Unfortunately, there is no equivalent counter-part function for new hook and the old one looks incompatible which we overlooked. This patch is switching the logic for kernels 5.9+ to custom implementation of refcount logic and it should address the issue reported as lkrg-org#338
Starting from kernel 5.9+ function 'put_seccomp_filter' has been inlined and unavailble for hooking. However, internal not-inline function was used to mitigate the problem. Unfortunately, there is no equivalent counter-part function for new hook and the old one looks incompatible which we overlooked. This patch is switching the logic for kernels 5.9+ to custom implementation of refcount logic and it should address the issue reported as #338
Kind of fixed via #346 |
On 5.9+, we use
__put_seccomp_filter
instead of the (no longer existent)put_seccomp_filter
. However, we still pair it withget_seccomp_filter
. This looks wrong at least for current mainline becauseget_seccomp_filter
increments two refcounts:whereas
__put_seccomp_filter
decrements just one. Do we possibly trigger a resource leak there? Refcount overflow or hopefully saturation risk, too?Looks like we'd need to use
__seccomp_filter_release
instead, or even the non-staticseccomp_filter_release
(for which we'd need a dummy task struct). Thosewake_up_poll
things don't look like something we normally want to do, but perhaps if it just happened that the seccomp filter was otherwise freed while we held it, then it becomes our responsibility to do this, too?The text was updated successfully, but these errors were encountered: