The Rust uutils projects produces a call to statx() with the pathname arg set to NULL. (See https://github.com/uutils/coreutils/issues/9440) For each of these pseduo produces this outpu: couldn't allocate absolute path for 'null'. However, pseudo should be trying to intercept calls *silently*. There is no point in reporting this as it is not an issue for pseudo itself. It should just pass on such a call verbatim. So, something like this would do it. --- pseudo_wrapfuncs.c 2025-11-16 22:06:26.667272802 +0000 +++ pseudo_wrapfuncs.c-new 2025-11-24 12:20:45.209366483 +0000 @@ -14477,7 +14477,7 @@ } int save_errno; - if (antimagic > 0) { + if (antimagic > 0 || !path) { /* call the real syscall */ pseudo_debug(PDBGF_SYSCALL, "statx calling real syscall.\n"); rc = (*real_statx)(dirfd, path, flags, mask, statxbuf);
Gordon, Thanks for the bug report. Triaging during the bug review meeting so I may miss some things. Can you explain what the steps to reproduce are? What layers and branches are you using (commit ids can be helpful). What build host distro are you using? Does this happen on master if you are using an older version?
This is with any version of yocto with my hosttools patch (16f268 "classes/base: prefer gnu-prefixed HOSTTOOLS") reverted. https://bugzilla.yoctoproject.org/show_bug.cgi?id=16028#c16 has some more context and thoughts. Copying Mark because I think he had some insights on IRC that I can't immediately find.
>> Can you explain what the steps to reproduce are? Basically all you have to do is use it on a Ubuntu 25.10 system which has rust coreutils in place. I'm using it to build OpenVix, which is based on OpenEmbeded, But this test script (which uses my own build of the pseudo 1.9.2, as Ubuntu only has 1.9.0) shows tke problem: ===== test.sh ===== #!/bin/sh # BASE=/GMLtemp/uutils-debug cd $BASE || exit # Set the environment variables to run pseudo # LD_PRELOAD=$BASE/pseudo-built/lib64/libpseudo.so PSEUDO_PREFIX=`pwd`/pseudo-built export LD_PRELOAD PSEUDO_PREFIX date ===== end ===== The output is: [gmllaptop]: ./test.sh couldn't allocate absolute path for 'null'. Thu Nov 27 17:12:47 GMT 2025
A workaround is the commit I mentioned, which stops using any of the uutils tools, but obviously we need to fix this in the medium term.
The relevant thing is that pseudo shouldn't be auditing the system calls by producing output.
If my memory is correct the system is being called with a statx call with a NULL path, which is questionably valid to do. The man page says statx should be called with an _empty_ string _AND_ AT_EMPTY_PATH flag. The issue with rust is that it's not being called with an _empty_ string, it's being called with _NULL_ and AT_EMPTY_PATH from the previous diagnostics. This happens to work, because the syscall into the kernel checks for AT_EMPTY_PATH _BEFORE_ checking the path string's contents. pseudo on the other hand always reviews the path, and if not empty (again not NULL) it then does what it does. If it's empty and AT_EMPTY_PATH is set, it does different magic through the AT mechanisms. So to ME it looks like either RUST violates the man page documentation, or the man page is wrong. It would be nice if we could get clarification on this first. Pseudo just seems to be highlighting the issue, since 'null' is not a valid path. Also skipping the call on !path isn't right either. It _IS_ an error no matter what if AT_EMPTY_PATH is not defined, but when that is set, additional processing may be necessary (may, not sure it actually is). I'm intending to find some time in December or early January to try Ubuntu 25.10 and try to work through this and some other issues people have mentioned related to the RUST utilities.
> If my memory is correct the system is being called with a statx call with a NULL path, which is questionably valid to do. Correct. But it IS (sort-of) valid to do it, as the this is a test to see what error code is returned. If it isn't EFAULT then the system isn;t able to do successful statx() calls > Also skipping the call on !path isn't right either. It _IS_ an error no matter what if AT_EMPTY_PATH is not defined, but when that is set, additional processing may be necessary (may, not sure it actually is). But it is NOT AN ERROR IN pseudo. So pseudo should NOT be printing out a diagnostic message about it: it should just make the real call and ignore the result (as it should for any other syscall with invalid args). The most it should do is report it in verbose mode.
> Also skipping the call on !path isn't right either. It is NOT skipping the call. It is only skipping the diagnostic message print out. > It _IS_ an error no matter what if AT_EMPTY_PATH is not defined, But it is NOT a pseudo error. In fact, it is not an error at all.
*** Bug 16099 has been marked as a duplicate of this bug. ***
> But it is NOT a pseudo error. In fact, it is not an error at all. And by that I mean it IS an error in pseudo at the moment! It should just pass-on the "illegal" call and ignore the result, ie. stay out of the way completely.
Is anyone interested in actually fixing this bug?
Hi Gordon, we are interested in resolving this issue. We have limited maintainer bandwidth and we're working though issues as best we can. Mark, I took a look at the rust standard library. The invalid call to statx() was added in Rust 1.40 (https://github.com/rust-lang/rust/commit/10f1bc77b3c404ebc1d386fc14453b6b32cf02bb, I love a commit message that just reads "Some tweaks"!) and still exists with slightly different ordering in Rust 1.92 (https://github.com/rust-lang/rust/blob/1.92.0/library/std/src/sys/fs/unix.rs#L195). The expectation is that this will set errno to EFAULT is the syscall exists - it's a deliberately invalid call. I also don't see the AT_EMPTY_PATH flag used in this particular call. Is it possible to detect a null path in the arguments passed by the caller of statx() and return an error before calling pseudo_root_path()?
>> Is it possible to detect a null path in the arguments passed by the caller of statx() and return an error before calling pseudo_root_path()? The simplest thing to do on detecting a NULL path is just to pass on the args to the real call (to ensure you get the right "real" result) and IGNORE the interception. It isn't going to do anything of interest to pseudo. And *most importantly* this should not produce any output
Note that I did supply a patch to handle the NULL path without producing output (although it probably needs a comment to explain the !path part).
Hi Gordon, pseudo_wrapfuncs.c is generated during the build so can't be patched directly. The if condition you changed comes from templates/wrapfuncs.c which is used for every wrapper, not just for the statx wrapper, so we can't change it there either. Hopefully Mark will have some ideas, if not then one of us needs to spend the time to understand where to place the check.
>> pseudo_wrapfuncs.c is generated during the build so can't be patched directly. I hadn't noticed that. Thanks for the explanation.
(In reply to Paul Barker from comment #12) > Hi Gordon, we are interested in resolving this issue. We have limited > maintainer bandwidth and we're working though issues as best we can. > > Mark, I took a look at the rust standard library. The invalid call to > statx() was added in Rust 1.40 > (https://github.com/rust-lang/rust/commit/ > 10f1bc77b3c404ebc1d386fc14453b6b32cf02bb, I love a commit message that just > reads "Some tweaks"!) and still exists with slightly different ordering in > Rust 1.92 > (https://github.com/rust-lang/rust/blob/1.92.0/library/std/src/sys/fs/unix. > rs#L195). The expectation is that this will set errno to EFAULT is the > syscall exists - it's a deliberately invalid call. I also don't see the > AT_EMPTY_PATH flag used in this particular call. > > Is it possible to detect a null path in the arguments passed by the caller > of statx() and return an error before calling pseudo_root_path()? Looking at that commit, it is truely terrible way to "optimize", and it's clearly the cause of this. They are expecting invalid behavior to, well behave is a specific way. The behavior itself is undefined, so in the future if it changes this will break uutils. It's really really stupid. I'm going to attempt to look into it further, but to emulate invalid/undefined behavior will probably require a change to the wrapper generation with an additional parameter that defines if certain NULL parameters should return back EFAULT. Which again is 100% undefined behavior, stupid.
Ohh and the undefined behavior is PROBABLY Linux GLIBC specific. So will it work on MUSL? BSD? etc the same way? Who knows.. but why should they care, it's FASTER! </sarcasm>
>> They are expecting invalid behavior to, well behave is a specific way. The behavior itself is undefined... The behaviour is NOT undefined. From the statx man page: EFAULT pathname or statxbuf is NULL or points to a location outside the process's accessible address space.
The behavior is undefined, it's docuemnted in the Linux man page, but the reason it happens is during the syscall for statx the copy from user to kernel space faults and returns back. This isn't standard POSIX behavior, this is Linux specific behavior. The only fix I can think of for this is to add a new parameter to the wrapper functions where you can declare variables that are not allowed to be null. If they are null they will EFAULT as an emulation short-cutting the whole call chain. This has to happen BEFORE the pseudo wrapper functions are called, based on parameters. Some of this validation is already in place for flags and other components, but not for invalid memory.
>> This isn't standard POSIX behavior, this is Linux specific behavior. And the thing that is triggering this issue is the build of a Linux OS, where using Linux-specific behaviour would appear to be reasonable. It's pseudo that has to fit in with this.
Possible implementation: https://git.yoctoproject.org/pseudo/commit/?h=fray/master-wip&id=34dfac8e3f78975b3871422a066cd0559fa18a21
The fix has been merged to pseudo master: https://git.yoctoproject.org/pseudo/commit/?id=9ce8c09980af23ebd4ebf072010469882d0459a6 If you are still experiencing the issue, please reopen this with details.
reopening the fix is not correct and results in locks not being cleared.
Fix for the dead lock issue: 9ce8c09980af23ebd4ebf072010469882d0459a6
Mark pushed additional commits to pseudo and Richard upsdated pseudo: https://git.openembedded.org/openembedded-core/commit/?id=8acdbefd0a148c8b7713f46066ae8489984c5d2d