[PATCH bpf v4] bpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk

[PATCH bpf v4] bpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk

[Pu Lehui]

From: Pu Lehui <pulehui@huawei.com>

Syzkaller repeatedly triggered UAF splats related to nodes in
waiting_for_gp_ttrace within the bpf memalloc:

BUG: KASAN: slab-use-after-free in llist_del_first+0x85/0x110 lib/llist.c:61
Read of size 8 at addr ffff8881572cd080 by task syz.4.470/5112
 ...
 llist_del_first+0x85/0x110 lib/llist.c:61
 alloc_bulk+0x193/0x460 kernel/bpf/memalloc.c:229
 bpf_mem_refill+0x386/0x560 kernel/bpf/memalloc.c:436

Freed by task 14:
 ...
 __free_rcu kernel/bpf/memalloc.c:281 [inline]
 __free_rcu_tasks_trace+0x48/0xd0 kernel/bpf/memalloc.c:291
 rcu_tasks_invoke_cbs+0x1ec/0x3e0 kernel/rcu/tasks.h:571
 rcu_tasks_one_gp+0x13d/0x220 kernel/rcu/tasks.h:621
 rcu_tasks_kthread+0xf3/0x120 kernel/rcu/tasks.h:651

The reason is that the UAF occurs after the RCU Tasks Trace GP expires:
when the __free_rcu() callback runs, there is no synchronization
protecting llist_del_all() against concurrent alloc_bulk() operating on
waiting_for_gp_ttrace, leading to the race condition below:

CPU0                                           CPU1
                                               __free_rcu (RCU Tasks Trace callback)
alloc_bulk
  llist_del_first(&c->waiting_for_gp_ttrace)
    entry = smp_load_acquire(&head->first);
    do {
      if (entry == NULL)
        return NULL;
                                               free_all(llist_del_all(&c->waiting_for_gp_ttrace))
                                                 llist_for_each_safe(pos, t, llnode)
                                                   free_one(pos);
      next = READ_ONCE(entry->next); <-- trigger UAF
    } while (!try_cmpxchg(&head->first, &entry, next));

In addition, there is also a theoretical race condition on the
free_by_rcu_ttrace list. This race requires two preconditions: an
in-flight Tasks Trace GP keeping c->call_rcu_ttrace_in_progress == 1,
and concurrent cross-CPU frees repopulating c->free_by_rcu_ttrace with
new nodes. Under these conditions, the following scenario triggers UAF:

// CPU0
// irq work is still busy (on PREEMPT_RT)
alloc_bulk()
  llist_del_first(&c->free_by_rcu_ttrace)
    entry = smp_load_acquire(&head->first);
    do {
      if (entry == NULL)
        return NULL;

        // CPU1
        bpf_mem_alloc_destroy()
          WRITE_ONCE(c->draining, true)
          // wait for CPU0
          irq_work_sync()

                // CPU2
                do_call_rcu_ttrace(tgt(CPU0))
                  if (c->draining) {
                    llist_del_all(&c->free_by_rcu_ttrace)
                    free_all()
                  }

// CPU0 continue
      next = READ_ONCE(entry->next); <-- trigger UAF
    while (!try_cmpxchg(&head->first, &entry, next));

Fix this by introducing a raw spinlock to synchronize the concurrent
consumption on waiting_for_gp_ttrace and free_by_rcu_ttrace.

Fixes: 04fabf00b4d3 ("bpf: Allow reuse from waiting_for_gp_ttrace list.")
Suggested-by: Alexei Starovoitov <ast@kernel.org>
Suggested-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
v4:
- Update comments for ttrace list in alloc_bulk. (BPF CI)
- Drop initial troubleshooting explaining in commit message.

v3: https://lore.kernel.org/bpf/20260901150307.3474349-1-pulehui@huaweicloud.com
- Fix concurrent issue also for free_by_rcu_ttrace. (bpfci and Hou Tao)
- Use scoped_guard. (Leon)

v2: https://lore.kernel.org/bpf/20260827084013.1062816-1-pulehui@huaweicloud.com
- Use raw spinlock to fix concurrent alloc_bulk and __free_rcu on
  waiting_for_gp_ttrace after GP. (Hou Tao)

v1: https://lore.kernel.org/bpf/20260826103615.932094-1-pulehui@huaweicloud.com

 kernel/bpf/memalloc.c | 50 ++++++++++++++++++++++++-------------------
 1 file changed, 28 insertions(+), 22 deletions(-)

diff --git a/kernel/bpf/memalloc.c b/kernel/bpf/memalloc.c
index e9662db7198f..8a8f088e83e6 100644
--- a/kernel/bpf/memalloc.c
+++ b/kernel/bpf/memalloc.c
@@ -119,6 +119,7 @@ struct bpf_mem_cache {
 	struct llist_head waiting_for_gp_ttrace;
 	struct rcu_head rcu_ttrace;
 	atomic_t call_rcu_ttrace_in_progress;
+	raw_spinlock_t lock;
 };
 
 struct bpf_mem_caches {
@@ -214,25 +215,24 @@ static void alloc_bulk(struct bpf_mem_cache *c, int cnt, int node, bool atomic)
 	gfp = __GFP_NOWARN | __GFP_ACCOUNT;
 	gfp |= atomic ? GFP_NOWAIT : GFP_KERNEL;
 
-	for (i = 0; i < cnt; i++) {
-		/*
-		 * For every 'c' llist_del_first(&c->free_by_rcu_ttrace); is
-		 * done only by one CPU == current CPU. Other CPUs might
-		 * llist_add() and llist_del_all() in parallel.
-		 */
-		obj = llist_del_first(&c->free_by_rcu_ttrace);
-		if (!obj)
-			break;
-		add_obj_to_free_list(c, obj);
-	}
-	if (i >= cnt)
-		return;
+	/*
+	 * c->lock serializes concurrent llist_del_first() against
+	 * llist_del_all() in __free_rcu() and do_call_rcu_ttrace().
+	 */
+	scoped_guard(raw_spinlock_irqsave, &c->lock) {
+		for (i = 0; i < cnt; i++) {
+			obj = llist_del_first(&c->free_by_rcu_ttrace);
+			if (!obj)
+				break;
+			add_obj_to_free_list(c, obj);
+		}
 
-	for (; i < cnt; i++) {
-		obj = llist_del_first(&c->waiting_for_gp_ttrace);
-		if (!obj)
-			break;
-		add_obj_to_free_list(c, obj);
+		for (; i < cnt; i++) {
+			obj = llist_del_first(&c->waiting_for_gp_ttrace);
+			if (!obj)
+				break;
+			add_obj_to_free_list(c, obj);
+		}
 	}
 	if (i >= cnt)
 		return;
@@ -279,8 +279,12 @@ static int free_all(struct bpf_mem_cache *c, struct llist_node *llnode, bool per
 static void __free_rcu(struct rcu_head *head)
 {
 	struct bpf_mem_cache *c = container_of(head, struct bpf_mem_cache, rcu_ttrace);
+	struct llist_node *llnode;
+
+	scoped_guard(raw_spinlock_irqsave, &c->lock)
+		llnode = llist_del_all(&c->waiting_for_gp_ttrace);
 
-	free_all(c, llist_del_all(&c->waiting_for_gp_ttrace), !!c->percpu_size);
+	free_all(c, llnode, !!c->percpu_size);
 	atomic_set(&c->call_rcu_ttrace_in_progress, 0);
 }
 
@@ -300,7 +304,8 @@ static void do_call_rcu_ttrace(struct bpf_mem_cache *c)
 
 	if (atomic_xchg(&c->call_rcu_ttrace_in_progress, 1)) {
 		if (unlikely(READ_ONCE(c->draining))) {
-			llnode = llist_del_all(&c->free_by_rcu_ttrace);
+			scoped_guard(raw_spinlock_irqsave, &c->lock)
+				llnode = llist_del_all(&c->free_by_rcu_ttrace);
 			free_all(c, llnode, !!c->percpu_size);
 		}
 		return;
@@ -535,6 +540,7 @@ int bpf_mem_alloc_init(struct bpf_mem_alloc *ma, int size, bool percpu)
 			c->objcg = objcg;
 			c->percpu_size = percpu_size;
 			c->tgt = c;
+			raw_spin_lock_init(&c->lock);
 			init_refill_work(c);
 			prefill_mem_cache(c, cpu);
 		}
@@ -557,7 +563,7 @@ int bpf_mem_alloc_init(struct bpf_mem_alloc *ma, int size, bool percpu)
 			c->objcg = objcg;
 			c->percpu_size = percpu_size;
 			c->tgt = c;
-
+			raw_spin_lock_init(&c->lock);
 			init_refill_work(c);
 			prefill_mem_cache(c, cpu);
 		}
@@ -609,7 +615,7 @@ int bpf_mem_alloc_percpu_unit_init(struct bpf_mem_alloc *ma, int size)
 		c->objcg = objcg;
 		c->percpu_size = percpu_size;
 		c->tgt = c;
-
+		raw_spin_lock_init(&c->lock);
 		init_refill_work(c);
 		prefill_mem_cache(c, cpu);
 	}
-- 
2.34.1

Re: [PATCH bpf v4] bpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 3164 bytes --]

> Syzkaller repeatedly triggered UAF splats related to nodes in
> waiting_for_gp_ttrace within the bpf memalloc:
> BUG: KASAN: slab-use-after-free in llist_del_first+0x85/0x110 lib/llist.c:61
> Read of size 8 at addr ffff8881572cd080 by task syz.4.470/5112
>  ...
>  llist_del_first+0x85/0x110 lib/llist.c:61
>  alloc_bulk+0x193/0x460 kernel/bpf/memalloc.c:229
>  bpf_mem_refill+0x386/0x560 kernel/bpf/memalloc.c:436
> Freed by task 14:
>  ...
>  __free_rcu kernel/bpf/memalloc.c:281 [inline]
>  __free_rcu_tasks_trace+0x48/0xd0 kernel/bpf/memalloc.c:291
>  rcu_tasks_invoke_cbs+0x1ec/0x3e0 kernel/rcu/tasks.h:571
>  rcu_tasks_one_gp+0x13d/0x220 kernel/rcu/tasks.h:621
>  rcu_tasks_kthread+0xf3/0x120 kernel/rcu/tasks.h:651

The file and line numbers in this stack trace refer to v6.6 (the v1
posting included 'Not tainted 6.6.0+', which was dropped in later
versions). Against the current tree, these line numbers point to different
locations: alloc_bulk() line 229 is in a blank/'if (i >= cnt)' section
(the waiting_for_gp_ttrace access is now at line 231), bpf_mem_refill()
line 436 is the closing brace, and __free_rcu_tasks_trace() no longer
exists at all (removed by commit 57b23c0f612d).

Should the stack trace include the kernel version to prevent future
readers from trying to map these line numbers onto the current tree?

> In addition, there is also a theoretical race condition on the
> free_by_rcu_ttrace list. This race requires two preconditions: an
> in-flight Tasks Trace GP keeping c->call_rcu_ttrace_in_progress == 1,
> and concurrent cross-CPU frees repopulating c->free_by_rcu_ttrace with
> new nodes. Under these conditions, the following scenario triggers UAF:
> // CPU0
> // irq work is still busy (on PREEMPT_RT)
> alloc_bulk()
>   llist_del_first(&c->free_by_rcu_ttrace)
>     entry = smp_load_acquire(&head->first);
>     do {
>       if (entry == NULL)
>         return NULL;
>         // CPU1
>         bpf_mem_alloc_destroy()
>           WRITE_ONCE(c->draining, true)
>           // wait for CPU0
>           irq_work_sync()
>                 // CPU2
>                 do_call_rcu_ttrace(tgt(CPU0))
>                   if (c->draining) {
>                     llist_del_all(&c->free_by_rcu_ttrace)
>                     free_all()
>                   }
> // CPU0 continue
>       next = READ_ONCE(entry->next); <-- trigger UAF

The annotation suggests this race window exists only on PREEMPT_RT
kernels. However, on non-PREEMPT_RT configurations, alloc_bulk() runs in
hard IRQ context and irq_work_sync() from another CPU still has to wait
for it, so the same race window exists there too. The earlier comment that
commit d114dde245f9 removed also mentioned non-RT cases: 'arch_irq_work_
has_interrupt() being false and irq work is invoked in timer interrupt.'

Would '(e.g., on PREEMPT_RT)' be more accurate than '(on PREEMPT_RT)' to
indicate this is an example rather than a precondition?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/33938697434

Re: [PATCH bpf v4] bpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk

[Pu Lehui]

On 2026/9/5 11:00, bot+bpf-ci@kernel.org wrote:
>> Syzkaller repeatedly triggered UAF splats related to nodes in
>> waiting_for_gp_ttrace within the bpf memalloc:
>> BUG: KASAN: slab-use-after-free in llist_del_first+0x85/0x110 lib/llist.c:61
>> Read of size 8 at addr ffff8881572cd080 by task syz.4.470/5112
>>   ...
>>   llist_del_first+0x85/0x110 lib/llist.c:61
>>   alloc_bulk+0x193/0x460 kernel/bpf/memalloc.c:229
>>   bpf_mem_refill+0x386/0x560 kernel/bpf/memalloc.c:436
>> Freed by task 14:
>>   ...
>>   __free_rcu kernel/bpf/memalloc.c:281 [inline]
>>   __free_rcu_tasks_trace+0x48/0xd0 kernel/bpf/memalloc.c:291
>>   rcu_tasks_invoke_cbs+0x1ec/0x3e0 kernel/rcu/tasks.h:571
>>   rcu_tasks_one_gp+0x13d/0x220 kernel/rcu/tasks.h:621
>>   rcu_tasks_kthread+0xf3/0x120 kernel/rcu/tasks.h:651
> 
> The file and line numbers in this stack trace refer to v6.6 (the v1
> posting included 'Not tainted 6.6.0+', which was dropped in later
> versions). Against the current tree, these line numbers point to different
> locations: alloc_bulk() line 229 is in a blank/'if (i >= cnt)' section
> (the waiting_for_gp_ttrace access is now at line 231), bpf_mem_refill()
> line 436 is the closing brace, and __free_rcu_tasks_trace() no longer
> exists at all (removed by commit 57b23c0f612d).
> 
> Should the stack trace include the kernel version to prevent future
> readers from trying to map these line numbers onto the current tree?

This is reproducible on mainline too, and the log makes the race pretty 
obvious at a glance. I don't think there's any real need to change it.

> 
>> In addition, there is also a theoretical race condition on the
>> free_by_rcu_ttrace list. This race requires two preconditions: an
>> in-flight Tasks Trace GP keeping c->call_rcu_ttrace_in_progress == 1,
>> and concurrent cross-CPU frees repopulating c->free_by_rcu_ttrace with
>> new nodes. Under these conditions, the following scenario triggers UAF:
>> // CPU0
>> // irq work is still busy (on PREEMPT_RT)
>> alloc_bulk()
>>    llist_del_first(&c->free_by_rcu_ttrace)
>>      entry = smp_load_acquire(&head->first);
>>      do {
>>        if (entry == NULL)
>>          return NULL;
>>          // CPU1
>>          bpf_mem_alloc_destroy()
>>            WRITE_ONCE(c->draining, true)
>>            // wait for CPU0
>>            irq_work_sync()
>>                  // CPU2
>>                  do_call_rcu_ttrace(tgt(CPU0))
>>                    if (c->draining) {
>>                      llist_del_all(&c->free_by_rcu_ttrace)
>>                      free_all()
>>                    }
>> // CPU0 continue
>>        next = READ_ONCE(entry->next); <-- trigger UAF
> 
> The annotation suggests this race window exists only on PREEMPT_RT
> kernels. However, on non-PREEMPT_RT configurations, alloc_bulk() runs in
> hard IRQ context and irq_work_sync() from another CPU still has to wait
> for it, so the same race window exists there too. The earlier comment that
> commit d114dde245f9 removed also mentioned non-RT cases: 'arch_irq_work_
> has_interrupt() being false and irq work is invoked in timer interrupt.'
> 
> Would '(e.g., on PREEMPT_RT)' be more accurate than '(on PREEMPT_RT)' to
> indicate this is an example rather than a precondition?

PREEMPT_RT was just a handy example here.

> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/33938697434

Re: [PATCH bpf v4] bpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk

[Hou Tao]

On 9/5/2026 10:11 AM, Pu Lehui wrote:
> From: Pu Lehui <pulehui@huawei.com>
>
> Syzkaller repeatedly triggered UAF splats related to nodes in
> waiting_for_gp_ttrace within the bpf memalloc:
>
> BUG: KASAN: slab-use-after-free in llist_del_first+0x85/0x110 lib/llist.c:61
> Read of size 8 at addr ffff8881572cd080 by task syz.4.470/5112
>  ...
>  llist_del_first+0x85/0x110 lib/llist.c:61
>  alloc_bulk+0x193/0x460 kernel/bpf/memalloc.c:229
>  bpf_mem_refill+0x386/0x560 kernel/bpf/memalloc.c:436
>
> Freed by task 14:
>  ...
>  __free_rcu kernel/bpf/memalloc.c:281 [inline]
>  __free_rcu_tasks_trace+0x48/0xd0 kernel/bpf/memalloc.c:291
>  rcu_tasks_invoke_cbs+0x1ec/0x3e0 kernel/rcu/tasks.h:571
>  rcu_tasks_one_gp+0x13d/0x220 kernel/rcu/tasks.h:621
>  rcu_tasks_kthread+0xf3/0x120 kernel/rcu/tasks.h:651
>
> The reason is that the UAF occurs after the RCU Tasks Trace GP expires:
> when the __free_rcu() callback runs, there is no synchronization
> protecting llist_del_all() against concurrent alloc_bulk() operating on
> waiting_for_gp_ttrace, leading to the race condition below:
>
> CPU0                                           CPU1
>                                                __free_rcu (RCU Tasks Trace callback)
> alloc_bulk
>   llist_del_first(&c->waiting_for_gp_ttrace)
>     entry = smp_load_acquire(&head->first);
>     do {
>       if (entry == NULL)
>         return NULL;
>                                                free_all(llist_del_all(&c->waiting_for_gp_ttrace))
>                                                  llist_for_each_safe(pos, t, llnode)
>                                                    free_one(pos);
>       next = READ_ONCE(entry->next); <-- trigger UAF
>     } while (!try_cmpxchg(&head->first, &entry, next));
>
> In addition, there is also a theoretical race condition on the
> free_by_rcu_ttrace list. This race requires two preconditions: an
> in-flight Tasks Trace GP keeping c->call_rcu_ttrace_in_progress == 1,
> and concurrent cross-CPU frees repopulating c->free_by_rcu_ttrace with
> new nodes. Under these conditions, the following scenario triggers UAF:
>
> // CPU0
> // irq work is still busy (on PREEMPT_RT)
> alloc_bulk()
>   llist_del_first(&c->free_by_rcu_ttrace)
>     entry = smp_load_acquire(&head->first);
>     do {
>       if (entry == NULL)
>         return NULL;
>
>         // CPU1
>         bpf_mem_alloc_destroy()
>           WRITE_ONCE(c->draining, true)
>           // wait for CPU0
>           irq_work_sync()
>
>                 // CPU2
>                 do_call_rcu_ttrace(tgt(CPU0))
>                   if (c->draining) {
>                     llist_del_all(&c->free_by_rcu_ttrace)
>                     free_all()
>                   }
>
> // CPU0 continue
>       next = READ_ONCE(entry->next); <-- trigger UAF
>     while (!try_cmpxchg(&head->first, &entry, next));
>
> Fix this by introducing a raw spinlock to synchronize the concurrent
> consumption on waiting_for_gp_ttrace and free_by_rcu_ttrace.
>
> Fixes: 04fabf00b4d3 ("bpf: Allow reuse from waiting_for_gp_ttrace list.")
> Suggested-by: Alexei Starovoitov <ast@kernel.org>
> Suggested-by: Hou Tao <houtao1@huawei.com>
> Signed-off-by: Pu Lehui <pulehui@huawei.com>

Acked-by: Hou Tao <houtao1@huawei.com>

Re: [PATCH bpf v4] bpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk

[Pu Lehui]

Gentle ping~

Hi all, Is this commit looks proper?

On 2026/9/5 10:11, Pu Lehui wrote:
> From: Pu Lehui <pulehui@huawei.com>
> 
> Syzkaller repeatedly triggered UAF splats related to nodes in
> waiting_for_gp_ttrace within the bpf memalloc:
> 
> BUG: KASAN: slab-use-after-free in llist_del_first+0x85/0x110 lib/llist.c:61
> Read of size 8 at addr ffff8881572cd080 by task syz.4.470/5112
>   ...
>   llist_del_first+0x85/0x110 lib/llist.c:61
>   alloc_bulk+0x193/0x460 kernel/bpf/memalloc.c:229
>   bpf_mem_refill+0x386/0x560 kernel/bpf/memalloc.c:436
> 
> Freed by task 14:
>   ...
>   __free_rcu kernel/bpf/memalloc.c:281 [inline]
>   __free_rcu_tasks_trace+0x48/0xd0 kernel/bpf/memalloc.c:291
>   rcu_tasks_invoke_cbs+0x1ec/0x3e0 kernel/rcu/tasks.h:571
>   rcu_tasks_one_gp+0x13d/0x220 kernel/rcu/tasks.h:621
>   rcu_tasks_kthread+0xf3/0x120 kernel/rcu/tasks.h:651
> 
> The reason is that the UAF occurs after the RCU Tasks Trace GP expires:
> when the __free_rcu() callback runs, there is no synchronization
> protecting llist_del_all() against concurrent alloc_bulk() operating on
> waiting_for_gp_ttrace, leading to the race condition below:
> 
> CPU0                                           CPU1
>                                                 __free_rcu (RCU Tasks Trace callback)
> alloc_bulk
>    llist_del_first(&c->waiting_for_gp_ttrace)
>      entry = smp_load_acquire(&head->first);
>      do {
>        if (entry == NULL)
>          return NULL;
>                                                 free_all(llist_del_all(&c->waiting_for_gp_ttrace))
>                                                   llist_for_each_safe(pos, t, llnode)
>                                                     free_one(pos);
>        next = READ_ONCE(entry->next); <-- trigger UAF
>      } while (!try_cmpxchg(&head->first, &entry, next));
> 
> In addition, there is also a theoretical race condition on the
> free_by_rcu_ttrace list. This race requires two preconditions: an
> in-flight Tasks Trace GP keeping c->call_rcu_ttrace_in_progress == 1,
> and concurrent cross-CPU frees repopulating c->free_by_rcu_ttrace with
> new nodes. Under these conditions, the following scenario triggers UAF:
> 
> // CPU0
> // irq work is still busy (on PREEMPT_RT)
> alloc_bulk()
>    llist_del_first(&c->free_by_rcu_ttrace)
>      entry = smp_load_acquire(&head->first);
>      do {
>        if (entry == NULL)
>          return NULL;
> 
>          // CPU1
>          bpf_mem_alloc_destroy()
>            WRITE_ONCE(c->draining, true)
>            // wait for CPU0
>            irq_work_sync()
> 
>                  // CPU2
>                  do_call_rcu_ttrace(tgt(CPU0))
>                    if (c->draining) {
>                      llist_del_all(&c->free_by_rcu_ttrace)
>                      free_all()
>                    }
> 
> // CPU0 continue
>        next = READ_ONCE(entry->next); <-- trigger UAF
>      while (!try_cmpxchg(&head->first, &entry, next));
> 
> Fix this by introducing a raw spinlock to synchronize the concurrent
> consumption on waiting_for_gp_ttrace and free_by_rcu_ttrace.
> 
> Fixes: 04fabf00b4d3 ("bpf: Allow reuse from waiting_for_gp_ttrace list.")
> Suggested-by: Alexei Starovoitov <ast@kernel.org>
> Suggested-by: Hou Tao <houtao1@huawei.com>
> Signed-off-by: Pu Lehui <pulehui@huawei.com>
> ---
> v4:
> - Update comments for ttrace list in alloc_bulk. (BPF CI)
> - Drop initial troubleshooting explaining in commit message.
> 
> v3: https://lore.kernel.org/bpf/20260901150307.3474349-1-pulehui@huaweicloud.com
> - Fix concurrent issue also for free_by_rcu_ttrace. (bpfci and Hou Tao)
> - Use scoped_guard. (Leon)
> 
> v2: https://lore.kernel.org/bpf/20260827084013.1062816-1-pulehui@huaweicloud.com
> - Use raw spinlock to fix concurrent alloc_bulk and __free_rcu on
>    waiting_for_gp_ttrace after GP. (Hou Tao)
> 
> v1: https://lore.kernel.org/bpf/20260826103615.932094-1-pulehui@huaweicloud.com
> 
>   kernel/bpf/memalloc.c | 50 ++++++++++++++++++++++++-------------------
>   1 file changed, 28 insertions(+), 22 deletions(-)
> 
> diff --git a/kernel/bpf/memalloc.c b/kernel/bpf/memalloc.c
> index e9662db7198f..8a8f088e83e6 100644
> --- a/kernel/bpf/memalloc.c
> +++ b/kernel/bpf/memalloc.c
> @@ -119,6 +119,7 @@ struct bpf_mem_cache {
>   	struct llist_head waiting_for_gp_ttrace;
>   	struct rcu_head rcu_ttrace;
>   	atomic_t call_rcu_ttrace_in_progress;
> +	raw_spinlock_t lock;
>   };
>   
>   struct bpf_mem_caches {
> @@ -214,25 +215,24 @@ static void alloc_bulk(struct bpf_mem_cache *c, int cnt, int node, bool atomic)
>   	gfp = __GFP_NOWARN | __GFP_ACCOUNT;
>   	gfp |= atomic ? GFP_NOWAIT : GFP_KERNEL;
>   
> -	for (i = 0; i < cnt; i++) {
> -		/*
> -		 * For every 'c' llist_del_first(&c->free_by_rcu_ttrace); is
> -		 * done only by one CPU == current CPU. Other CPUs might
> -		 * llist_add() and llist_del_all() in parallel.
> -		 */
> -		obj = llist_del_first(&c->free_by_rcu_ttrace);
> -		if (!obj)
> -			break;
> -		add_obj_to_free_list(c, obj);
> -	}
> -	if (i >= cnt)
> -		return;
> +	/*
> +	 * c->lock serializes concurrent llist_del_first() against
> +	 * llist_del_all() in __free_rcu() and do_call_rcu_ttrace().
> +	 */
> +	scoped_guard(raw_spinlock_irqsave, &c->lock) {
> +		for (i = 0; i < cnt; i++) {
> +			obj = llist_del_first(&c->free_by_rcu_ttrace);
> +			if (!obj)
> +				break;
> +			add_obj_to_free_list(c, obj);
> +		}
>   
> -	for (; i < cnt; i++) {
> -		obj = llist_del_first(&c->waiting_for_gp_ttrace);
> -		if (!obj)
> -			break;
> -		add_obj_to_free_list(c, obj);
> +		for (; i < cnt; i++) {
> +			obj = llist_del_first(&c->waiting_for_gp_ttrace);
> +			if (!obj)
> +				break;
> +			add_obj_to_free_list(c, obj);
> +		}
>   	}
>   	if (i >= cnt)
>   		return;
> @@ -279,8 +279,12 @@ static int free_all(struct bpf_mem_cache *c, struct llist_node *llnode, bool per
>   static void __free_rcu(struct rcu_head *head)
>   {
>   	struct bpf_mem_cache *c = container_of(head, struct bpf_mem_cache, rcu_ttrace);
> +	struct llist_node *llnode;
> +
> +	scoped_guard(raw_spinlock_irqsave, &c->lock)
> +		llnode = llist_del_all(&c->waiting_for_gp_ttrace);
>   
> -	free_all(c, llist_del_all(&c->waiting_for_gp_ttrace), !!c->percpu_size);
> +	free_all(c, llnode, !!c->percpu_size);
>   	atomic_set(&c->call_rcu_ttrace_in_progress, 0);
>   }
>   
> @@ -300,7 +304,8 @@ static void do_call_rcu_ttrace(struct bpf_mem_cache *c)
>   
>   	if (atomic_xchg(&c->call_rcu_ttrace_in_progress, 1)) {
>   		if (unlikely(READ_ONCE(c->draining))) {
> -			llnode = llist_del_all(&c->free_by_rcu_ttrace);
> +			scoped_guard(raw_spinlock_irqsave, &c->lock)
> +				llnode = llist_del_all(&c->free_by_rcu_ttrace);
>   			free_all(c, llnode, !!c->percpu_size);
>   		}
>   		return;
> @@ -535,6 +540,7 @@ int bpf_mem_alloc_init(struct bpf_mem_alloc *ma, int size, bool percpu)
>   			c->objcg = objcg;
>   			c->percpu_size = percpu_size;
>   			c->tgt = c;
> +			raw_spin_lock_init(&c->lock);
>   			init_refill_work(c);
>   			prefill_mem_cache(c, cpu);
>   		}
> @@ -557,7 +563,7 @@ int bpf_mem_alloc_init(struct bpf_mem_alloc *ma, int size, bool percpu)
>   			c->objcg = objcg;
>   			c->percpu_size = percpu_size;
>   			c->tgt = c;
> -
> +			raw_spin_lock_init(&c->lock);
>   			init_refill_work(c);
>   			prefill_mem_cache(c, cpu);
>   		}
> @@ -609,7 +615,7 @@ int bpf_mem_alloc_percpu_unit_init(struct bpf_mem_alloc *ma, int size)
>   		c->objcg = objcg;
>   		c->percpu_size = percpu_size;
>   		c->tgt = c;
> -
> +		raw_spin_lock_init(&c->lock);
>   		init_refill_work(c);
>   		prefill_mem_cache(c, cpu);
>   	}

Re: [PATCH bpf v4] bpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk

[Alexei Starovoitov]

On Thu Sep 10, 2026 at 6:17 PM PDT, Pu Lehui wrote:
> Gentle ping~
>
> Hi all, Is this commit looks proper?

Sorry. swamped. It's on my todo list.

Re: [PATCH bpf v4] bpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk

[Alexei Starovoitov]

On Fri, Sep 4, 2026 at 7:06 PM Pu Lehui <pulehui@huaweicloud.com> wrote:
>
> From: Pu Lehui <pulehui@huawei.com>
>
> Syzkaller repeatedly triggered UAF splats related to nodes in
> waiting_for_gp_ttrace within the bpf memalloc:
>
> BUG: KASAN: slab-use-after-free in llist_del_first+0x85/0x110 lib/llist.c:61
> Read of size 8 at addr ffff8881572cd080 by task syz.4.470/5112
>  ...
>  llist_del_first+0x85/0x110 lib/llist.c:61
>  alloc_bulk+0x193/0x460 kernel/bpf/memalloc.c:229
>  bpf_mem_refill+0x386/0x560 kernel/bpf/memalloc.c:436
>
> Freed by task 14:
>  ...
>  __free_rcu kernel/bpf/memalloc.c:281 [inline]
>  __free_rcu_tasks_trace+0x48/0xd0 kernel/bpf/memalloc.c:291
>  rcu_tasks_invoke_cbs+0x1ec/0x3e0 kernel/rcu/tasks.h:571
>  rcu_tasks_one_gp+0x13d/0x220 kernel/rcu/tasks.h:621
>  rcu_tasks_kthread+0xf3/0x120 kernel/rcu/tasks.h:651
>
> The reason is that the UAF occurs after the RCU Tasks Trace GP expires:
> when the __free_rcu() callback runs, there is no synchronization
> protecting llist_del_all() against concurrent alloc_bulk() operating on
> waiting_for_gp_ttrace, leading to the race condition below:
>
> CPU0                                           CPU1
>                                                __free_rcu (RCU Tasks Trace callback)
> alloc_bulk
>   llist_del_first(&c->waiting_for_gp_ttrace)
>     entry = smp_load_acquire(&head->first);
>     do {
>       if (entry == NULL)
>         return NULL;
>                                                free_all(llist_del_all(&c->waiting_for_gp_ttrace))

Thank you both for the fix!
Took me some time to page-in all this tricky logic.

Applied.

Re: [PATCH bpf v4] bpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to bpf/bpf.git (master)
by Alexei Starovoitov <ast@kernel.org>:

On Sat,  5 Sep 2026 02:11:39 +0000 you wrote:
> From: Pu Lehui <pulehui@huawei.com>
> 
> Syzkaller repeatedly triggered UAF splats related to nodes in
> waiting_for_gp_ttrace within the bpf memalloc:
> 
> BUG: KASAN: slab-use-after-free in llist_del_first+0x85/0x110 lib/llist.c:61
> Read of size 8 at addr ffff8881572cd080 by task syz.4.470/5112
>  ...
>  llist_del_first+0x85/0x110 lib/llist.c:61
>  alloc_bulk+0x193/0x460 kernel/bpf/memalloc.c:229
>  bpf_mem_refill+0x386/0x560 kernel/bpf/memalloc.c:436
> 
> [...]

Here is the summary with links:
  - [bpf,v4] bpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk
    https://git.kernel.org/bpf/bpf/c/1c21452d02ee

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html