RT-Thread / RT-Thread/rt-thread
[Bug] Control Flow Hijacking Issue in sys_device_init Operation in RT-Thread
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 12.2k
- Forks
- 5.4k
- Avg merge
- 4d 12h
- Merged PRs (30d)
- 40
Description
RT-Thread Version
5.1.0
Hardware Type/Architectures
N/A
Develop Toolchain
Other
Describe the bug
Summary
I have identified a critical vulnerability in the sys_device_init system call in RT-Thread. I am opening this issue for your review, as I could not find a reporting email in the security policy of this repository. This vulnerability stems from insufficient pointer validation and could allow an attacker to achieve arbitrary code execution through control flow hijacking. The issue is particularly severe as it could be exploited by a compromised user thread to gain elevated privileges.
Vulnerable Code Location
The vulnerability is present in the following files:
components/drivers/core/device.c: Contains the vulnerable macro definition and implementationcomponents/lwp/lwp_syscall.c: Contains the system call implementation
Vulnerability Description
The vulnerability exists in the device_init macro and its usage:
#define device_init (dev->ops ? dev->ops->init : RT_NULL)
In lwp_syscall.c:
sysret_t sys_device_init(rt_device_t dev)
{
return rt_device_init(dev);
}
In rt_device_init:
if (device_init != RT_NULL)
{
if (!(dev->flag & RT_DEVICE_FLAG_ACTIVATED))
{
result = device_init(dev); // Vulnerable call
if (result != RT_EOK)
{
LOG_E("To initialize device:%.*s failed. The error code is %d",
RT_NAME_MAX, dev->parent.name, result);
}
else
{
dev->flag |= RT_DEVICE_FLAG_ACTIVATED;
}
}
}
The code only performs a NULL check on the function pointer but fails to verify whether the pointer points to valid memory or a valid function. This oversight can lead to control flow hijacking when the function pointer is called.
Impact
This vulnerability has severe security implications:
-
Arbitrary Code Execution: An attacker could potentially corrupt the
dev->ops->initfunction pointer to point to arbitrary memory locations, leading to arbitrary code execution. -
Privilege Escalation: Since this vulnerability exists in the kernel space, successful exploitation could lead to privilege escalation.
-
System Compromise: The ability to execute arbitrary code in kernel space could lead to complete system compromise.
Mitigation
- Implement proper validation of function pointers before calling them
- Add additional checks to verify the integrity of the device structure
- Consider implementing Control Flow Integrity (CFI) mechanisms
- Add bounds checking for pointer dereferencing
References
- RT-Thread source code:
components/drivers/core/device.c - RT-Thread source code:
components/lwp/lwp_syscall.c
Other additional context
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the device_init implementation in components/drivers/core/device.c and the sys_device_init entry point in components/lwp/lwp_syscall.c, then trace how device pointers and operation callbacks are supplied. Confirm the reported threat and agree with maintainers on the validation or control-flow-integrity boundary; done means the security fix and its verification are documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- embedded-iot, operating-systems, security
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100