应用补丁段错误

**【缺陷描述】：请补充详细的缺陷问题现象描述**

**【问题复现步骤】：请描述具体的操作步骤**

应用补丁段错误

```bash
/usr/libexec/syscare/upatch-manage -v "patch" "--uuid" "57f8f65a-9f8c-4830-a64d-d6d6a90a1b1d" "--pid" "17054" "--binary" "/usr/libexec/qemu-kvm" "--upatch" "/usr/lib/syscare/patches/a3e36dee-2197-4c6f-bea3-54fee2428918/qemu-kvm"
```

**【实际结果】**，请描述出问题的结果和影响
```bash
Attached to 13 thread(s): 17054, 17082, 17087, 17088, 17089, 17090, 17091, 17092, 17094, 17096, 17631, 17634, 17637                                                                                                 
load_bias = 560567bf5000                                                                                                                                                                                            
[17054] Stack size 12976, region [0x7ffd411a4d50, 0x7ffd411a8000]                                                                                                                                                   
[17082] Stack size 8388608, region [0x7fde94212628, 0x7fde94a12628]                                                                                                                                                 
[17087] Stack size 18446744073709551615, region [0x0, 0xffffffffffffffff]                                                                                                                                           
段错误（核心已转储）   
```

**【期望结果】**，请描述出期望的结果和影响
应用补丁成功
**【其他相关附件信息】**
比如系统message日志/组件日志、dump信息、图片等

**【缺陷详情及分析指导参考链接】**

程序在尝试读取进程堆栈时出现了段错误（segmentation fault）。特别注意这一行：

```
[17087] Stack size 18446744073709551615, region [0x0, 0xffffffffffffffff]
```

这个数值 `18446744073709551615` 等于 `0xFFFFFFFFFFFFFFFF`，也就是 `ULONG_MAX`，这表明 [read_stack](./syscare/upatch-manage/upatch-stack-check.c#L60-L64) 函数或相关代码在读取某个线程的堆栈信息时出现了问题。

这个问题很可能发生在 [upatch-manage](./syscare/upatch-manage/) 模块中，让我们看看相关代码：

根据你的输出和代码分析，问题是由于 [read_stack](./syscare/upatch-manage/upatch-stack-check.c#L60-L64) 函数返回了一个无效的大小值，导致后续的循环出现严重问题。

具体来说，从日志可以看到：

```
[17087] Stack size 18446744073709551615, region [0x0, 0xffffffffffffffff]
```

这个值实际上是 `SIZE_MAX`（最大的无符号长整数），这表示 [pread](./syscare/syscare-common/src/fs/fs_impl.rs#L245-L245) 系统调用失败并返回了 -1，但是在转换为 [size_t](./syscare/syscare-build/src/patch/kernel_patch/mod.rs#L22-L22) 类型时变成了最大的无符号整数。

在 [upatch-stack-check.c](./syscare/upatch-manage/upatch-stack-check.c) 文件中，[read_stack](./syscare/upatch-manage/upatch-stack-check.c#L60-L64) 函数直接返回 [pread](./syscare/syscare-common/src/fs/fs_impl.rs#L245-L245) 的结果，没有检查错误情况：

```c
static size_t read_stack(struct upatch_process *proc,
    unsigned long *stack, size_t size, unsigned long sp)
{
    return (size_t)pread(proc->memfd, (void *)stack, size, (off_t)sp);
}
```

当 [pread](./syscare/syscare-common/src/fs/fs_impl.rs#L245-L245) 返回 -1 时（表示错误），它被强制转换为 [size_t](./syscare/syscare-build/src/patch/kernel_patch/mod.rs#L22-L22)，变成 SIZE_MAX，然后在后续的循环中：

```c
for (size_t i = 0; i < stack_size / sizeof(*stack); i++) {
```

这会导致一个巨大的循环次数，最终导致段错误。

解决方案是在 [read_stack](./syscare/upatch-manage/upatch-stack-check.c#L60-L64) 函数中增加错误检查：

```c
static size_t read_stack(struct upatch_process *proc,
    unsigned long *stack, size_t size, unsigned long sp)
{
    ssize_t result = pread(proc->memfd, (void *)stack, size, (off_t)sp);
    if (result < 0) {
        log_error("Failed to read stack from process memory: %s\n", strerror(errno));
        return 0;
    }
    return (size_t)result;
}
```

并且在调用点也应该检查返回值：

```c
stack_size = read_stack(proc, stack, stack_size, sp);
if (stack_size == 0) {
    log_warn("Failed to read stack for PID %d, skipping stack check\n", pid);
    free(stack);
    return 0;
}
```

这个 bug 会导致在对某些进程进行热补丁操作时发生段错误，特别是在处理某些特殊线程（比如内核线程或其他特权线程）时，因为这些线程的堆栈可能无法通过 `/proc/<pid>/mem` 正常访问。

openEuler/syscare
关闭

内容风险标识

评论 (2)

openEuler/syscare关闭 .gitee-modal { width: 500px !important; }

内容风险标识