RT-Thread Version
master at commit 25295501c0cc7181d6a541a867fdf7214879ddf8, also present in released tags that I checked, including: v5.2.2, v5.2.1, v5.2.0, v5.1.0, v5.0.2, v4.1.1, v4.0.4, v4.0.0, v3.1.5, and v3.0.4.
Hardware Type/Architectures
Any BSP / architecture with RT_USING_FINSH, DFS_USING_POSIX, and DFS_USING_WORKDIR enabled.
Develop Toolchain
GCC
Describe the bug
Summary
There is a format-string vulnerability in the FinSH/MSH prompt printing path.
finsh_get_prompt() appends the current working directory to the prompt buffer via getcwd(), and the result is later passed directly to rt_kprintf() as the format string in components/finsh/shell.c.
The vulnerable call is:
components/finsh/shell.c:545 → rt_kprintf(FINSH_PROMPT);
The same unsafe pattern also appears later in the same file when the prompt is printed again after command handling.
This means the shell prompt becomes attacker-controlled when the working directory name contains format specifiers. A local user can create or enter a directory such as %08x%08x%08x, and the next prompt print will interpret that directory name as a format string instead of plain text.
Source-to-sink chain:
- Source: user-controlled directory name from
mkdir argv[1] / cd argv[1]
- Propagation:
getcwd() in finsh_get_prompt()
- Sink:
rt_kprintf(FINSH_PROMPT)
Impact:
- Information disclosure / stack data leak via
%x, %p, %s
- Possible crash / denial of service
- In builds where
%n support is enabled, this may also allow memory write behavior
Steps to Reproduce
- Build RT-Thread with
RT_USING_FINSH, DFS_USING_POSIX, and DFS_USING_WORKDIR enabled.
- Boot into the MSH shell.
- Create a directory whose name contains format specifiers:
- Change into that directory:
- Observe the next shell prompt.
- The
%08x sequences are interpreted by rt_kprintf() and stack values may be printed instead of the literal directory name.
Expected Behavior
The prompt should print the working directory literally and must not treat it as a format string.
A safe fix is to use a constant format string:
rt_kprintf("%s", FINSH_PROMPT);
This should be applied to every prompt-printing location in components/finsh/shell.c.
Kindly let me know if you intend to request a CVE ID upon confirmation of the vulnerability.
Other additional context
No response
RT-Thread Version
masterat commit25295501c0cc7181d6a541a867fdf7214879ddf8, also present in released tags that I checked, including:v5.2.2,v5.2.1,v5.2.0,v5.1.0,v5.0.2,v4.1.1,v4.0.4,v4.0.0,v3.1.5, andv3.0.4.Hardware Type/Architectures
Any BSP / architecture with
RT_USING_FINSH,DFS_USING_POSIX, andDFS_USING_WORKDIRenabled.Develop Toolchain
GCC
Describe the bug
Summary
There is a format-string vulnerability in the FinSH/MSH prompt printing path.
finsh_get_prompt()appends the current working directory to the prompt buffer viagetcwd(), and the result is later passed directly tort_kprintf()as the format string incomponents/finsh/shell.c.The vulnerable call is:
components/finsh/shell.c:545→rt_kprintf(FINSH_PROMPT);The same unsafe pattern also appears later in the same file when the prompt is printed again after command handling.
This means the shell prompt becomes attacker-controlled when the working directory name contains format specifiers. A local user can create or enter a directory such as
%08x%08x%08x, and the next prompt print will interpret that directory name as a format string instead of plain text.Source-to-sink chain:
mkdir argv[1]/cd argv[1]getcwd()infinsh_get_prompt()rt_kprintf(FINSH_PROMPT)Impact:
%x,%p,%s%nsupport is enabled, this may also allow memory write behaviorSteps to Reproduce
RT_USING_FINSH,DFS_USING_POSIX, andDFS_USING_WORKDIRenabled.cd %08x%08x%08x%08xsequences are interpreted byrt_kprintf()and stack values may be printed instead of the literal directory name.Expected Behavior
The prompt should print the working directory literally and must not treat it as a format string.
A safe fix is to use a constant format string:
This should be applied to every prompt-printing location in
components/finsh/shell.c.Kindly let me know if you intend to request a CVE ID upon confirmation of the vulnerability.
Other additional context
No response