sched/group: skip group_release for kernel thread group#18826
Open
wyr-7 wants to merge 1 commit intoapache:masterfrom
Open
sched/group: skip group_release for kernel thread group#18826wyr-7 wants to merge 1 commit intoapache:masterfrom
wyr-7 wants to merge 1 commit intoapache:masterfrom
Conversation
6b021c5 to
108a3e6
Compare
108a3e6 to
e607b27
Compare
When CONFIG_DISABLE_PTHREAD=y, HAVE_GROUP_MEMBERS is undefined and group_leave() unconditionally calls group_release() for every exiting thread. This destroys the shared g_kthread_group resources (mutex, fdlist, task_info) while other kernel threads are still using them, causing use-after-free crashes. Fix by checking TCB_FLAG_TTYPE_KERNEL in group_leave() before calling group_release(), so the entire release path is skipped for kernel threads. This is safe because g_kthread_group is statically allocated and its lifetime is the entire system. Signed-off-by: wangyongrong <wangyongrong@xiaomi.com>
e607b27 to
0d11eee
Compare
xiaoxiang781216
approved these changes
Apr 30, 2026
xiaoxiang781216
approved these changes
May 1, 2026
acassis
reviewed
May 1, 2026
| group = tcb->group; | ||
| if (group) | ||
| { | ||
| bool release = !(tcb->flags & TCB_FLAG_TTYPE_KERNEL); |
Contributor
There was a problem hiding this comment.
Please include comment here explaining the idea of this new modification
Contributor
|
Could you please take a look at this approach and verify @mzanders? :-) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When CONFIG_DISABLE_PTHREAD=y, HAVE_GROUP_MEMBERS is undefined and group_leave() unconditionally calls group_release() for every exiting thread. This destroys the shared g_kthread_group resources (mutex, fdlist, task_info) while other kernel threads are still using them, causing use-after-free crashes.
PR #18517 added GROUP_FLAG_STATIC to guard group_drop() against freeing the static g_kthread_group struct. However, group_release() still runs and destroys internal resources (tg_mutex, tg_fdlist, tg_info) that are shared by all kernel threads.
Fix by checking TCB_FLAG_TTYPE_KERNEL in group_leave() before calling group_release(), so the entire release path is skipped for kernel threads. This is safe because g_kthread_group is statically allocated and its lifetime is the entire system.
Also fix the "Bits 3-7: Available" comment to "Bits 5-7" since bit 4 is now used by GROUP_FLAG_FD_BACKTRACE.
Impact
All configurations with CONFIG_DISABLE_PTHREAD=y that dynamically create and destroy kernel threads have fixed use-after-free.
Testing
Tested on Infineon TC4D9 EVB (TriCore, NuttX SMP BMP). Verified kernel thread exit does not corrupt shared g_kthread_group by stopping an rptun channel (destroys rpmsg kthread).
Before rptun stop (rpmsg-corecs-0 kthread PID 48 present):
After rptun stop (rpmsg-corecs-0 gone, all other kthreads intact):
System continues running normally after kthread exit. No crash, no assert, no corruption of g_kthread_group resources. PID 48 (rpmsg-corecs-0) successfully destroyed while 20+ other kernel threads sharing the same g_kthread_group remain healthy.