代码审计是使用静态分析发现源代码中安全缺陷的方法，辅助开发或测试人员在软件上线前较为全面地了解安全问题,防患于未然，因此一直以来都是学术界和产业界研究的热点，并已成为安全开发生命周期 SDL 和 DevSecOps 等保障体系的重要技术手段。
奇安信代码卫士团队基于自主研发的国内首款源代码安全检测商用工具，以及十余年漏洞技术研究的积累，推出“缺陷周话”系列栏目。每周针对 CWE、OWASP 等标准中的一类缺陷，结合实例和工具使用进行详细介绍，旨在为广大开发和安全人员提供代码审计的基础性标准化教程。
1、重复加锁
所有针对互斥量的加锁解锁操作，都必须针对同一模块并且在同一抽象层面进行，否则将会可能导致某些加锁/解锁操作不会依照多线程设计而被执行，重复加锁即对已经加锁的资源进行再次加锁。
2、“重复加锁”的危害
某些情况下，重复加锁操作会导致第二次加锁操作要等待前一次加锁的解锁操作，由于加锁操作的重复，被等待的行为永远无法达到，造成死锁、程序拒绝服务等漏洞。CVE中也有一些与之相关的漏洞信息，从2019年1月至2019年11月，CVE中就有1条相关漏洞信息。漏洞信息如下：
| CVE | 概述 |
|---|---|
| CVE-2019-14763 | Linux kernel 4.16.4之前版本的drivers/usb/dwc3/gadget.c 中存在一个 double-locking error（重复加锁错误），导致死锁问题。 |
3、示例代码
示例源于toyota-itc-benchmarks-master (https://github.com/regehr/itc-benchmarks)，源文件名：double_lock.c。
3.1 缺陷代码
在上述示例代码中，第40行使用 pthread_mutex_lock() 函数对double_lock_001_glb_mutex 进行加锁操作，在没有进行解锁的情况下，第42行再次使用 pthread_mutex_lock() 函数对double_lock_001_glb_mutex 进行加锁操作，因此存在“重复加锁”问题。使用代码卫士对上述示例代码进行检测，可以检出“重复加锁”缺陷，显示等级为中。如图1所示：
图1：“重复加锁”检测示例
3.2 修复代码
在上述修复代码中，第40行使用 pthread_mutex_lock() 函数对double_lock_001_glb_mutex 进行加锁操作，在第42行使用pthread_mutex_unlock() 对其进行解锁，此时第44行再次进行加锁操作时，就避免了重复加锁问题。使用代码卫士对修复后的代码进行检测，可以看到已不存在“重复加锁”缺陷。如图2：
图2：修复后检测结果
4、如何避免“重复加锁”
（1）在进行加锁操作时，需要检查代码逻辑，避免对已经进行锁定的互斥量进行重复加锁。（2）当互斥量类型为PTHREAD_MUTEX_ERRORCHECK时，会提供错误检查。如果某个线程尝试重新锁定的互斥锁已经由该线程锁定，则将返回错误。
推荐阅读
【缺陷周话】第56期：ContentProvider URI 注入
【缺陷周话】第44期：Spring Boot 配置错误：不安全的 Actuator
【缺陷周话】第 24期：在scanf 函数中没有对 %s 格式符进行宽度限制
*奇安信代码卫士团队原创出品。未经许可，禁止转载。转载请注明“转自奇安信代码卫士 www.codesafe.cn”。
来源：freebuf.com 2019-11-15 20:35:55 by: 奇安信代码卫士
请登录后发表评论
注册