对haproxy进行lib库注入和系统调用注入，出现三种类型core文件

【OS版本】：被测的版本信息

openEuler_x86_64

compiletime=2023-05-23-12-12-21

kernelversion=5.10.0-136.12.0.86.h921

【测试类型】：发现问题的测试类型，功能测试、可靠性测试、性能测试等

可靠性测试

一、执行lib库注入命令/工具类测试

1.cd afi/example/intercept_lib/not_daemon

2.修改testcase.sh

[root@openEuler not_daemon]# cat testcase.sh

# testcase

haproxy gcc Makefile

# for EFAULT ,the sut must check asan error

# Returns false when an error occurs

exit 0

3.执行greedy策略

[root@openEuler not_daemon]# cat test_greedy.sh

sh /usr/local/inject_syscall/bin/run_lib_inject.sh -p /usr/sbin/haproxy -H -s greedy -m inject -c "sh $/testcase.sh"

#执行测试

sh test_greedy.sh

二、执行系统调用注入命令/工具类测试

1.cd /root/afi/example/intercept_syscall/not_daemon/grep_greedy

2.注入系统调用故障：

[root@openEuler grep_dfs]# cat test_EFAULT.sh

[root@localhost grep_greedy]#  cat test_EFAULT.sh

#! /bin/bash

sh /usr/local/inject_syscall/bin/run_inject.sh -T EFAULT -p /usr/sbin/haproxy -s greedy -m inject -c "sh $/test_command_for_EFAULT"

[root@openEuler grep_greedy]# cat test_command_for_EFAULT

# testcase

haproxy make Makefile

# for EFAULT ,the sut must check asan error

# Returns false when an error occurs

exit 0

sh  test_EFAULT.sh

【结果输出】：根据上述测试步骤执行后，系统的实际输出

一、产生100+core文件，主要为这三种类型

二、产生两个core文件

与一的第一个core完全一样

【预期输出】：系统在上述测试步骤操作后，按照系统设计应该输出的结果

不应该产生core文件

【测试代码】：发现问题的测试代码，或者关键片段，能指导问题复现

一、

sh bug_log/2023-05-23-15-15-41-105898124/replay_cmd-haproxy-2023-05-23-15-15-41-105898124.sh

sh bug_log/2023-05-23-15-15-34-714214744/replay_cmd-haproxy-2023-05-23-15-15-34-714214744.sh

二、

/root/afi/example/intercept_syscall/not_daemon/grep_greedy

sh bug_log/2023-05-24-14-59-10-067335959/replay_cmd-haproxy-2023-05-24-14-59-10-067335959.sh

【初步定位结论】：已明确的相关定位信息或者相关的沟通交流信息

NA

【是否新引入rpm包，是否进行了安全编译选项扫描】

否

【定位分析】

一、对haproxy进行lib库注入

a. 类型1

pthread_create 会调用malloc进行内存分配，故障注入使内存申请失败，而haproxy代码中没有对pthread_create是否成功进行判断，导致后续调用pthread_join的时候出现问题

合入社区补丁进行修复：https://github.com/haproxy/haproxy/commit/ef667b1ad89bb159b1991de0ec07d17e4320df23

b. 类型2

BIO_meth_new may会调用malloc对ha_meth进行内存分配，故障注入使内存申请失败，而haproxy代码中没有对ha_meth进行检查，导致后续调用BIO_meth_set_write写入的时候出现问题

合入社区补丁进行修复：https://github.com/haproxy/haproxy/commit/15c3d20e315f1f06c9649ae598de86d61d41085b

c. 类型3

usermsgs_put会使用malloc为usermsgs_buf.area申请内存，故障注入使内存申请失败，而haproxy代码中没有对usermsgs_buf.area进行检查，导致后续b_putblk进行写入的时候出现问题

合入社区补丁进行修复：https://github.com/haproxy/haproxy/commit/d4dba38ab101eee4cbd0c8d8aa21181825ef6472

二、 对haproxy进行系统调用注入

a. 类型1

同一、a有相同堆栈，可用相同补丁修复

b. 类型2

ring_new使用malloc进行内存分配，内存申请时候的失败发生在glibc，代码有check_malloc_state进行判断，只是欧拉未开启debug开关；而haproxy中有对于malloc之后的结果是否成功做判断，代码符合预期，非问题：

【对外部是否有影响】

否

src-openEuler/haproxy
关闭

内容风险标识

评论 (1)

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

内容风险标识