-
-
[原创]CVE-2022-2602 内核提权详细分析
-
发表于: 2025-3-7 15:15 1699
-
CVE-2022-2602 内核提权详细分析
漏洞简介
漏洞编号: CVE-2022-2602
影响版本:Linux Kernel < v6.0.3。v6.0.3已修复。
漏洞产品: linux kernel - io_uring & unix_gc
利用效果: 本地提权
环境搭建
复现环境:qemu + linux kernel v5.18.19
环境附件: mowenroot/Kernel
复现流程: 执行exp后,账号:mowen,密码:mowen的root用户被添加。su mowen完成提权。
漏洞原理
漏洞本质是 filp
的 UAF
。 io_uring
模块提供的 io_uring_register
系统调用中的 IORING_REGISTER_FILES
能注册文件。调用后会把文件放入 io_uring->sk->receive_queue
。在 Linux gc
垃圾回收机制中又会将该列表的文件取出,尝试会将文件取出并释放。导致下次使用 io_uring
利用该文件时会触发 UAF
。
漏洞技术点涉及 io_uring 、飞行计数、gc回收机制等,涉及的还是比较多的,下面详细分析。
参考链接:
【kernel exploit】CVE-2022-2602垃圾回收错误释放iouring的file导致UAF — bsauce
io_uring, SCM_RIGHTS, and reference-count cycles(729K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6D9N6$3&6Q4x3X3g2F1k6i4c8Q4x3V1k6m8M7Y4c8A6j5$3I4W2M7#2)9J5c8U0M7%4z5e0b7%4x3W2)9J5c8W2)9J5z5b7`.`.
The quantum state of Linux kernel garbage collection CVE-2021-0920 (Part I)(56dK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4L8$3!0Y4L8r3g2H3M7X3!0B7k6h3y4@1P5X3g2J5L8#2)9J5k6h3u0D9L8$3N6K6M7r3!0@1i4K6u0W2j5$3!0E0i4K6u0r3x3U0l9J5x3W2)9J5c8U0l9^5i4K6u0r3N6r3S2W2i4K6u0V1M7i4g2S2L8Y4c8#2L8g2)9J5k6s2y4@1j5i4c8W2i4K6u0V1L8$3k6Q4x3X3c8D9K9h3&6#2P5q4)9J5k6r3E0W2M7X3&6W2L8q4)9J5k6h3S2@1L8h3I4Q4x3U0V1`.
飞行计数
Linux 进程间通信是很重要的一个功能。Linux sock就允许建立一个双向socket来传递消息,通常会在两个进程中通信使用。SCM_RIGHTS 是 Unix 域套接字(Unix Domain Socket)中用于 进程间传递文件描述符的控制消息类型。其核心作用在于允许两个进程通过 IPC 机制共享已打开的文件、套接字或其他资源,而无需重复打开或复制数据。接下来主要针对 SCM_RIGHTS 方面分析。
但是传递总会有影响,比如我这边发送过去,对方还没接收到就关闭了文件。对方该怎么处理,不可能再去使用已经释放的资源。所以在文件准备发送的阶段,就会对文件引用计数 +1
。即使在对方没接收到就关闭文件,他的引用计数才不会为 0
而被释放。这样在socket
被关闭时,调用sock_release
对未接受到的文件,使用 fput()
来减少引用计数,这样就可以正常使用文件。
在资源释放比较依赖于 socket
被关闭,但是我发送 socket fd
本身,这样就会造成无法释放。比如下图
1、打开两个sock A、B,初始引用计数都是为 1 。
2、把 A 发送给 B ,B 发送给 A。两个引用计数都 +1 ,这时 ref_A==ref_B==2 。
3、关闭用户态的文件描述符,即关闭 A、B。引用计数都会 -1 ,这时 ref_A==ref_B==1。
4、用户态已经无法再次对 A、B 操作,也就无法调用sock_release
,但是内核又不会主动对 A、B 操作,就导致了资源无法释放。
这样 Linux gc
垃圾回收机制就诞生了,内核会主动回收这种类似的资源,下面详细分析。先来了解发送的一个过程,再来分析回收机制。
发送SCM_RIGHTS
在用户态使用 socketpair(AF_UNIX,SOCK_DGRAM,0,s);
申请 SOCK_DGRAM
类型的 socket
然后使用 sendmsg()
发送 SCM_RIGHTS
类型的信息的时候,会调用unix_dgram_sendmsg()
。
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
|
/* net/unix/af_unix.c */ static int unix_dgram_sendmsg( struct socket *sock, struct msghdr *msg,
size_t len)
{ struct sock *sk = sock->sk; // 获取socket对应的sock结构
DECLARE_SOCKADDR( struct sockaddr_un *, sunaddr, msg->msg_name); // 获取目标地址
struct sock *other = NULL; // other为目标socket(如果没指定地址默认为对端)
struct sk_buff *skb; // skb数据缓冲区
struct scm_cookie scm; // 用于传递文件描述符等控制消息
wait_for_unix_gc(); // 等待垃圾回收完成
// 获取文件结构体file ,初始化 scm_cookie
err = scm_send(sock, msg, &scm, false );
// ...
// 处理目标地址
if (msg->msg_namelen) {
// 如果指定了目标地址,验证地址有效性
err = unix_validate_addr(sunaddr, msg->msg_namelen);
if (err)
goto out;
} else {
// 未指定目标地址,尝试获取已连接的对端
sunaddr = NULL;
err = -ENOTCONN;
// other为对端
other = unix_peer_get(sk);
if (!other)
goto out;
}
// ...
// 分配发送缓冲区
skb = sock_alloc_send_pskb(sk, len - data_len, data_len,
msg->msg_flags & MSG_DONTWAIT, &err,
PAGE_ALLOC_COSTLY_ORDER);
if (skb == NULL)
goto out;
// 将 scm_cookie 添加到skb 文件的发送工作
err = unix_scm_to_skb(&scm, skb, true );
if (err < 0)
goto out_free;
//...
// 把skb添加到 对端的sk_receive_queue(未接收列表)
skb_queue_tail(&other->sk_receive_queue, skb);
unix_state_unlock(other);
// 通知接收进程有数据到达
other->sk_data_ready(other);
sock_put(other);
// 销毁 scm_cookie
scm_destroy(&scm);
return len;
//... return err;
} |
「1」 首先会调用 scm_send
获取文件结构体 file
,初始化 scm_cookie
。这个 scm_cookie
涉及文件存放的列表,并且前面提到的准备发送阶段的文件引用计数增加,就在这个函数中实现。 相关结构体如下。
1
2
3
4
5
6
7
8
9
10
11
12
|
struct scm_cookie {
struct pid * pid; /* 0 8 */
struct scm_fp_list * fp; //文件列表 /* 8 8 */
struct scm_creds creds; /* 16 12 */
struct lsmblob lsmblob; /* 28 16 */
}; struct scm_fp_list {
short int count; /* 0 2 */
short int max; /* 2 2 */
struct user_struct * user; /* 8 8 */
struct file * fp[253]; /* 16 2024 */
}; |
「2」初始化了相关文件,接着需要处理发送目的,other
为目标 socket
,如果没指定地址就会通过 unix_peer_get()
获取已连接的对端,比如在最开始的描述中,把 A
发送给 B
,other
在这里就是为 B
。
「3」 接下来处理发送数据,把 scm_cookie
中的文件添加到 skb
,并且还会对文件引用计数与飞行计数增加操作等。
「4」 把当前 skb
挂载到对方的 sk_receive_queue
(未接收列表),然后通知对方有数据要来,最后通过 scm_destroy
销毁局部变量 scm_cookie
,减少最开始增加的引用计数。需要注意的是 scm_destroy
减少的只是局部变量引用增加的,不是准备发送阶段增加的。
scm_send函数
约等于直接调用了__scm_send()
,重点关注 SCM_RIGHTS
,在这个选择中调用 scm_fp_copy
来获取file结构体,初始化 scm_cookie->fp
文件列表,并把 file
结构体放入文件数组( fp->fp
)中。
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
|
/* net/core/scm.c */ int __scm_send( struct socket *sock, struct msghdr *msg, struct scm_cookie *p)
{ struct cmsghdr *cmsg;
// 遍历控制头
for_each_cmsghdr(cmsg, msg) {
//...
switch (cmsg->cmsg_type)
{
case SCM_RIGHTS: // 传递文件描述符
// 必须是UNIX域socket
if (!sock->ops || sock->ops->family != PF_UNIX)
goto error;
// 获取 file 结构体
err=scm_fp_copy(cmsg, &p->fp);
if (err<0)
goto error;
break ;
//...
}
//... } |
scm_fp_copy
「1」 首先会对文件列表进行初始化,再尝试把文件放入文件数组。
「2」 会循环使用 fget_raw()
从文件描述符中获取 file
结构体,过程中引用计数 +1
,这里 +1 是前面提到的局部变量引用增加的,不是准备发送阶段增加的。在之后的 scm_destroy()
中会对应减少,到这里我们对 scm_cookie
有了更深的理解,无非就是两层结构,大致可看为 文件列表 -> 文件数组的关系。现在做的操作就是需要初始化文件列表,然后把要发送的文件存放进文件数组中。
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
|
/* net/unix/af_unix.c */ static int scm_fp_copy( struct cmsghdr *cmsg, struct scm_fp_list **fplp)
{ int *fdp = ( int *)CMSG_DATA(cmsg);
struct scm_fp_list *fpl = *fplp;
struct file **fpp;
int i, num;
// 获取数量
num = (cmsg->cmsg_len - sizeof ( struct cmsghdr))/ sizeof ( int );
if (num <= 0)
return 0;
if (num > SCM_MAX_FD)
return -EINVAL;
// fpl 文件列表,如果文件列表为空,则进行初始化
if (!fpl)
{
// 分配空间 使用GFP_KERNEL_ACCOUNT
fpl = kmalloc( sizeof ( struct scm_fp_list), GFP_KERNEL_ACCOUNT);
if (!fpl)
return -ENOMEM;
// 初始化参数
*fplp = fpl;
fpl->count = 0; // 文件个数
fpl->max = SCM_MAX_FD; // 文件最大数量
fpl->user = NULL;
}
// 获取文件列表中的文件数组位置
fpp = &fpl->fp[fpl->count];
if (fpl->count + num > fpl->max)
return -EINVAL;
// 遍历所有文件结构体
for (i=0; i< num; i++)
{
int fd = fdp[i];
struct file *file;
// fget_raw 获取文件结构体,引用计数 +1
// 这里 +1 是前面提到的局部变量引用增加的,不是准备发送阶段增加的
if (fd < 0 || !(file = fget_raw(fd)))
return -EBADF;
*fpp++ = file; //存放进数组
// 文件列表计数,count为文件结构体个数
fpl->count++;
}
if (!fpl->user)
fpl->user = get_uid(current_user());
return num;
} |
unix_scm_to_skb
「1」 该函数主要工作是将 scm_cookie
添加到 skb
,进行文件的发送工作。设置一些 cb
信息后调用 unix_attach_fds()
。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
/* net/unix/af_unix.c */ static int unix_scm_to_skb( struct scm_cookie *scm, struct sk_buff *skb, bool send_fds)
{ int err = 0;
// 初始化 skb->cb
UNIXCB(skb).pid = get_pid(scm->pid);
UNIXCB(skb).uid = scm->creds.uid;
UNIXCB(skb).gid = scm->creds.gid;
UNIXCB(skb).fp = NULL;
unix_get_secdata(scm, skb);
// 文件列表存在,即有文件时调用unix_attach_fds
if (scm->fp && send_fds)
err = unix_attach_fds(scm, skb);
skb->destructor = unix_destruct_scm;
return err;
} |
unix_attach_fds
「1」 到这里就是核心发送阶段了,先调用 scm_fp_dup()
对每个文件增加文件计数引用,在这里才是准备发送阶段增加的计数引用,之前获取 file
使用的 fget_raw()
增加是临时的,代表 scm
正在引用。
「2」 然后调用 unix_inflight()
尝试添加飞行计数。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
/* net/unix/scm.c */ int unix_attach_fds( struct scm_cookie *scm, struct sk_buff *skb)
{ int i;
if (too_many_unix_fds(current))
return -ETOOMANYREFS;
/*
* Need to duplicate file references for the sake of garbage
* collection. Otherwise a socket in the fps might become a
* candidate for GC while the skb is not yet queued.
*/
// scm_fp_dup 会为 scm->fp 中所有文件 增加计数引用
UNIXCB(skb).fp = scm_fp_dup(scm->fp);
if (!UNIXCB(skb).fp)
return -ENOMEM;
// 遍历每个文件,尝试添加飞行计数
for (i = scm->fp->count - 1; i >= 0; i--)
unix_inflight(scm->fp->user, scm->fp->fp[i]);
return 0;
} |
scm_fp_dup
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
/* net/core/scm.c */ struct scm_fp_list *scm_fp_dup( struct scm_fp_list *fpl)
{ struct scm_fp_list *new_fpl;
int i;
if (!fpl)
return NULL;
// 复制新的文件列表
new_fpl = kmemdup(fpl, offsetof( struct scm_fp_list, fp[fpl->count]),
GFP_KERNEL_ACCOUNT);
if (new_fpl) {
// 准备发送阶段的引用计数 +1
for (i = 0; i < fpl->count; i++)
get_file(fpl->fp[i]);
new_fpl->max = new_fpl->count;
new_fpl->user = get_uid(fpl->user);
}
return new_fpl;
} |
unix_inflight
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
|
/* net/unix/scm.c */ void unix_inflight( struct user_struct *user, struct file *fp)
{ // 获取sock(只有socket和io_uring才能找到)
struct sock *s = unix_get_socket(fp);
spin_lock(&unix_gc_lock);
//对于sock类增加飞行计数
if (s) {
struct unix_sock *u = unix_sk(s);
// inc自增u->inflight,飞行计数不存放在file,而是在文件对应的sock
// 当第一次增加inflight时,添加到全局飞行列表 gc_inflight_list
if (atomic_long_inc_return(&u->inflight) == 1) {
BUG_ON(!list_empty(&u->link));
list_add_tail(&u->link, &gc_inflight_list);
} else {
BUG_ON(list_empty(&u->link));
}
/* Paired with READ_ONCE() in wait_for_unix_gc() */
// 全局飞行计数 +1
WRITE_ONCE(unix_tot_inflight, unix_tot_inflight + 1);
}
// 用户inflight计数++
user->unix_inflight++;
spin_unlock(&unix_gc_lock);
} |
「1」 因为只有在发送 socket
自身的 fd
才会导致资源无法释放的问题,在普通文件引用的情况都会在 sock_release()
中释放,所以在添加飞行引用计数只考虑 sock
类(socket和io_uring)。通过 unix_get_socket()
获取 sock
,而这只有 socket
和 io_uring
才能找到。普通文件返回 NULL
。接着会对 sock
类进行特殊处理。
unix_get_socket
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
/* net/unix/scm.c */ struct sock *unix_get_socket( struct file *filp)
{ struct sock *u_sock = NULL;
struct inode *inode = file_inode(filp); //获取inode
/* Socket ? */
// socket情况
if (S_ISSOCK(inode->i_mode) && !(filp->f_mode & FMODE_PATH)) {
struct socket *sock = SOCKET_I(inode);
struct sock *s = sock->sk;
/* PF_UNIX ? */
if (s && sock->ops && sock->ops->family == PF_UNIX)
u_sock = s;
} else {
/* Could be an io_uring instance */
// 获取io_uring的sock
u_sock = io_uring_get_socket(filp);
}
return u_sock;
} |
「2」 如果存在则会 inc
自增u->inflight
,前面提到飞行计数并不涉及普通文件,只针对 sock
类,所以当然的飞行计数不存放在 file
,而是在文件对应的 sock
。当第一次增加 inflight
时,添加到全局飞行列表 gc_inflight_list
。这点很关键,当使用 unix_gc()
回收时就会在 gc_inflight_list
找出符合的释放。
即如果传进来的是 socket
或者 io_uring
会进行以下操作:
-
增加飞行计数——
u->inflight++
-
添加到全局飞行队列
gc_inflight_list
-
全局飞行计数增加
unix_tot_inflight++
-
用户飞行计数增加
user->unix_inflight++
scm_destroy
「1」首先销毁cred,释放文件列表调用 __scm_destroy()
「2」遍历文件列表,使用 fput()
减少文件计数引用,抵消最开始 fget_raw()
增加的文件引用计数。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
/* include/net/scm.h */ static __inline__ void scm_destroy( struct scm_cookie *scm)
{ scm_destroy_cred(scm);
if (scm->fp)
__scm_destroy(scm);
} /* net/core/scm.c */ void __scm_destroy( struct scm_cookie *scm)
{ struct scm_fp_list *fpl = scm->fp;
int i;
if (fpl) {
scm->fp = NULL;
for (i=fpl->count-1; i>=0; i--)
fput(fpl->fp[i]);
free_uid(fpl->user);
kfree(fpl);
}
} |
飞行计数小结
通过上面的分析,我们大致对发送 SCM_RIGHTS
和 飞行计数 有了一个大致的了解。
文件初始阶段——在发送文件描述符时,会先通过 fd
获取 file
结构体,以数组列表形式挂载到局部变量 scm_cookie
。
文件准发阶段——再把局部变量 scm_cookie
中的文件列表添加到 skb
上。同时增加文件计数引用,防止未接受就关闭的风险。并增加飞行引用计数和挂载到全局飞行列表 gc_inflight_list
,而飞行引用计数只有 sock
类(socket、io_uring)再会增加,普通文件不做处理。
文件发送阶段——添加各种附加信息,把当前 skb
挂载到对端未接受列表(sk_receive_queue
),并通知进程有数据到达。
资源销毁阶段——因为 scm_cookie
为局部变量,并在第一阶段采用 fget_raw()
增加文件计数引用,在这一阶段需要安全释放资源见减少文件引用计数然后函数返回。
unix_gc垃圾回收机制
[招生]科锐逆向工程师培训(2025年3月11日实地,远程教学同时开班, 第52期)!