Repository navigation
Stack buffer overflow in dlt_logstorage_storage_dir_info() #896
Description
Activity
Explain "121-byte stack buffer".
Why does not the kernel FS cannot be trusted to handle this?
Can you turn this into a hypothesis, experiment, observation, verdict loop?
Hello, @fizzl
- Explain "121-byte stack buffer".
tmpfile is a local array in the loop of dlt_logstorage_storage_dir_info(), so it's on the stack.
dlt_offline_logstorage_behavior.c:431:
char tmpfile[DLT_OFFLINE_LOGSTORAGE_MAX_LOG_FILE_LEN + 1] = { '\0' };DLT_OFFLINE_LOGSTORAGE_MAX_FILE_NAME_LEN = 100 DLT_OFFLINE_LOGSTORAGE_TIMESTAMP_LEN = 16 DLT_OFFLINE_LOGSTORAGE_INDEX_LEN = 3 DLT_OFFLINE_LOGSTORAGE_MAX_LOG_FILE_LEN = 100 + 16 + 3 + 1 = 120Array size = 120 + 1 = 121 bytes
This is a stack-allocated buffer.
- Why does not the kernel FS cannot be trusted to handle this?
The kernel caps filenames at NAME_MAX ((255 bytes for most filesystems) ), but the stack buffer is only 121 bytes — so the kernel's limit is already more than double the buffer size.- Can you turn this into a hypothesis, experiment, observation, verdict loop?
It is simple to trigger this problem.
You can reproduce it yourself as follows.
To verify the hypothesis that an unbounded strcat overflows the 121-byte tmpfile buffer, we conducted a PoC test using an ASan (AddressSanitizer) build. After creating a filename longer than 121 bytes using a Python one-liner (python3 -c "open('ECU_' + 'A'*247 + '.dlt', 'w').close()"), we triggered the dlt-daemon. As expected, ASan successfully detected a stack-buffer-overflow precisely at line 437 during the strcat operation."
- Alex, someone, kickban please…On Sun, 12 Jul 2026, 5.08 cryptcrack, ***@***.***> wrote: *cryptcrack* left a comment (COVESA/dlt-daemon#896) <#896 (comment)> Hello, @fizzl <https://github.com/fizzl> 1. Explain "121-byte stack buffer". tmpfile is a local array in the loop of dlt_logstorage_storage_dir_info(), so it's on the stack. dlt_offline_logstorage_behavior.c:431: char tmpfile[DLT_OFFLINE_LOGSTORAGE_MAX_LOG_FILE_LEN + 1] = { '\0' }; DLT_OFFLINE_LOGSTORAGE_MAX_FILE_NAME_LEN = 100 DLT_OFFLINE_LOGSTORAGE_TIMESTAMP_LEN = 16 DLT_OFFLINE_LOGSTORAGE_INDEX_LEN = 3 DLT_OFFLINE_LOGSTORAGE_MAX_LOG_FILE_LEN = 100 + 16 + 3 + 1 = 120 Array size = 120 + 1 = 121 bytes This is a stack-allocated buffer. 2. Why does not the kernel FS cannot be trusted to handle this? The kernel caps filenames at NAME_MAX ((255 bytes for most filesystems) ), but the stack buffer is only 121 bytes — so the kernel's limit is already more than double the buffer size. 3. Can you turn this into a hypothesis, experiment, observation, verdict loop? It is simple to trigger this problem. You can reproduce it yourself as follows. To verify the hypothesis that an unbounded strcat overflows the 121-byte tmpfile buffer, we conducted a PoC test using an ASan (AddressSanitizer) build. After creating a filename longer than 121 bytes using a Python one-liner (python3 -c "open('ECU_' + 'A'*247 + '.dlt', 'w').close()"), we triggered the dlt-daemon. As expected, ASan successfully detected a stack-buffer-overflow precisely at line 437 during the strcat operation." — Reply to this email directly, view it on GitHub <#896?email_source=notifications&email_token=AAMEGNFP5N47IROENBEXTLD5ELXLNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJUHE2TMOJXGY42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4949569769>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMEGNBW7XRVO2ECCBUMD4L5ELXLNAVCNFSNUABEKJSXA33TNF2G64TZHM3DQMZQGY2TQNR3JFZXG5LFHM2DQMRYGQYDENRQHCQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAMEGNB4DKOMDFLUXOURTXD5ELXLNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJUHE2TMOJXGY42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AAMEGNBRJWPD4VMKYS2URCT5ELXLNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJUHE2TMOJXGY42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>Reacted by cryptcrack
@fizzl Hmm.. Why are you conducting a kickban?
- linked a pull request that will close this issue[Prior 3] Fix dlt memleak #918
on Sep 21, 2026 - added a commit that references this issue
on Oct 8, 2026
Summary
A stack-based buffer overflow exists in the DLT Offline Logstorage feature of dlt-daemon.
When Offline Logstorage is enabled, dlt-daemon scans the configured logstorage directory to collect existing log files. During this process, dlt_logstorage_storage_dir_info() concatenates the directory component and the scanned file name into a fixed-size stack buffer using strcat() without validating the combined length.
Vulnerable Code
Root Cause
The root cause is unsafe concatenation of filesystem-controlled file names into a fixed-size stack buffer.
dlt_logstorage_storage_dir_info() calls scandir() on the Offline Logstorage directory:
Each matching directory entry is processed based on only a weak prefix/delimiter check:
As a result, a long directory component from the file= configuration and a long matching file name in the logstorage directory can overflow the 121-byte stack buffer.
Log
Impact