Re: [PATCH] busybox: fix TOCTOU race in various directory traversal
On Sun, 1 Feb 2026 at 12:57, Sertonix via busybox wrote: > > > Please describe exact testcases of the attacks you defend against. > > I have attached a demonstration script for the issue with rm -r. The > script intentionally slows down the rm process to make the issue easier > to reproduce but the same issue should be possible (but potentially > difficult) without. The TOCTOU race is possible when between the fstat > call stat call used to check for a directory and the opendir call to get > a fd for the directory. Between these moments the directory can be > replaced with a symlink pointing to any path and opendir will follow > that symlink when getting the fd. This should help increasing the latency and thus increase the chance to see the expected race condition nice -n19 ionice -c3 stdbuf -o0 -e0 -i0 \ strace -o slow-1 busybox rm -r -f -v tmp > slow-2 Best regards, R- ___ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] busybox: fix TOCTOU race in various directory traversal
> Please describe exact testcases of the attacks you defend against. I have attached a demonstration script for the issue with rm -r. The script intentionally slows down the rm process to make the issue easier to reproduce but the same issue should be possible (but potentially difficult) without. The TOCTOU race is possible when between the fstat call stat call used to check for a directory and the opendir call to get a fd for the directory. Between these moments the directory can be replaced with a symlink pointing to any path and opendir will follow that symlink when getting the fd. The same pattern of *stat + opendir exists in multiple places of the code and I decided to proactively harden these code paths against potential similar issues as well by changing the shared recursive_action. One might notice that even with my change a directory could have been replaced with a symlink between stat and opendir but that was mitigated by using O_DIRECTORY|O_NOFOLLOW (or other calls that would fail if the type changed). > The code is going to be evolving in the future. > The future core readers need to understand > what needs to be avoided, I understand, please ask again if something wasn't understandable enough! test.sh Description: application/shellscript ___ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] busybox: fix TOCTOU race in various directory traversal
On Sun, 1 Feb 2026 at 10:31, Denys Vlasenko via busybox wrote: > > Please describe exact testcases of the attacks you defend against. > Because the patchset was provided in downloadable files, I decided to check how Gemini 3 Fast would react at this request https://gemini.google.com/app/2a7a4f75926d930c As you can see, I did not provided to the AI no any support but simply answering "yes" (aka yes | gemini -p $initial-prompt). I did few experiments in the past and the output ALWAYS required manual intervention, never reaching an acceptable conclusion on its own. In this case, I am expecting the same pattern of failure (did not check yet, just shared for the moment). Why should we care? For those who have a background yet, the AI can stimulate learning (not good, not bad, by itself: everything depends on the mindset, as usual). For those who are mastering the subject, it is a quickest and cheapest option to collect ideas (unless scrutinizing every byte of the AI output is taken as per default policy, in that case we are working for AI not the AI for us [*]). Finally, because AI exists and it is not going to fade away just because we ignore it, thus better know. By the way, this doesn't mean that everybody should know (everything) but it matters that someone does. [*] this claim has several exceptions outside coding, for example in text generation in which the human review is essential and mandatory. Within coding, when the AI is asked to create a canvas which let us start coding without facing the blank-page wall or simply because the starting canvas is so "common" that it is fine to delegate to an automated tool rather than writing the same boring cycles and error checks in which usually humans fail more than AI because typos or similar attention/keyboard glitches. Best regards, R- ___ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] busybox: fix TOCTOU race in various directory traversal
Please describe exact testcases of the attacks you defend against. (You can describe them in replies to this email, instead of resending everything) The code is going to be evolving in the future. The future core readers need to understand what needs to be avoided, On Sat, Jan 31, 2026 at 3:06 PM Sertonix via busybox wrote: > > > Also results in a binary size shrink by sharing more code :) > > Without this a process having write access to a directory could trick > a more privilidged rm -r call to delete any file that the rm process > has access to. > ___ > busybox mailing list > [email protected] > https://lists.busybox.net/mailman/listinfo/busybox ___ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
