Fedora Account System
Red Hat Associate
Red Hat Customer
Linux 7.2 introduced EFTYPE, so when my kernel package was upgraded it is now defined in errno.h: ``` $ dnf history info 716 | grep kernel-0 Install kernel-0:7.2.4-200.fc44.x86_64 User updates Remove kernel-0:7.1.10-200.fc44.x86_64 User @System $ printf '#include <errno.h>\n int main () { int value = EFTYPE; return value; }' | gcc -E - | tail -n 5 int main () { int value = # 2 "<stdin>" 3 134 # 2 "<stdin>" ; return value; } ``` However, glibc was not rebuilt so it has no error strings corresponding to the error. For strerrorname_np it means a NULL pointer is unexpectedly returned: ``` $ cat main.c #define _GNU_SOURCE 1 #include <stdio.h> #include <string.h> #include <errno.h> int main (void) { printf ("%s\n", strerror (EPERM)); printf ("%s\n", strerrorname_np (EPERM)); printf ("%s\n", strerror (EFTYPE)); printf ("%s\n", strerrorname_np (EFTYPE)); return 0; } $ gcc main.c; ./a.out Operation not permitted EPERM Unknown error 134 Segmentation fault (core dumped) ./a.out ``` If dereferenced the program will crash like the above example. Reproducible: Always Steps to Reproduce: 1. Compile a program calling printf ("%s\n", strerrorname_np (EFTYPE)); 2. Run it Actual Results: It crashes. Expected Results: It should print EFTYPE.
The strerrorname_np API is not described as being tied to the running kernel on the system. You must always check the return of strerrorname_np since the API contract specifies that it may return NULL. You cannot make an apriori assumption that because the distribution kernel has the type EFTYPE, and that you upgraded to it, that the API will return a non-NULL result. The Linux 7.2 kernel entered Fedora 44 a week ago, but glibc 2.43 was updated a month ago. At some point a glibc strerrorname_np call will return a non-NULL result for EFTYPE, but there are no guarantees about when that occurs. Consider for example a very old container running glibc on a very new kernel, the API will return NULL for many types that are present on the newer kernel but which glibc doesn't know about. This is not a bug, but perhaps a QoI on how the data is handled (at build time vs. dynamically loaded).
Collin, Does that answer your question? I would consider closing this as CLOSED / NOTABUG if you agree.
I disagree and believe it is still a bug. The current behavior of strerror, strerrorname_np, and strerrordesc_np is as if EFTYPE does not exist. It looks like an application that uses openat2 (..., OPENAT2_REGULAR) would encounter a confusing error in some cases at the moment [1]. I can test it later. The strerrorname_np and strerrordesc_np functions aren't documented with much detail, but I don't think anyone would expect it to fail with a support error number, e.g., when passing a constant defined in errno.h. Perhaps it could be considered minor, though. [1] https://github.com/torvalds/linux/commit/8b82cacad92ebae9619872a5a69c570eba30140b
(In reply to Collin Funk from comment #3) > I disagree and believe it is still a bug. The current behavior of strerror, > strerrorname_np, and strerrordesc_np is as if EFTYPE does not exist. It > looks like an application that uses openat2 (..., OPENAT2_REGULAR) would > encounter a confusing error in some cases at the moment [1]. I can test it > later. If glibc's strerrorname_np returns NULL it means *glibc* doesn't know about the error type. It doesn't mean the error isn't a valid kernel error though. To check that you'd need a vDSO version of strerrorname_np that uses live kernel data. That would be a valid and conforming implementation. > The strerrorname_np and strerrordesc_np functions aren't documented with > much detail, but I don't think anyone would expect it to fail with a support > error number, e.g., when passing a constant defined in errno.h. The argument that the kernel headers at time of application build matters to the runtime result is not logically correct. The application may be built with newer kernel headers but run on an older kernel. The application may be built with a newer glibc, but run on an ABI compatible version that doesn't know about that kernel error value. This happens frequently in build and production systems, it can happen with checkpoint restore in userspace, etc. > Perhaps it could be considered minor, though. Why would we consider it a bug? It does what the API documentation says it does. If there is an expectation gap it is a QoI issue, that we could do *better* if we had a vDSO version of this call. Though keep in mind such an implementation may one minute return NULL and another minute return ETYPE, depending on the exact kernel version. While today you get a consistent answer in userspace if glibc is kept constant.
Thanks for the detailed explanations and sorry for the confusion. I think I agree. You can close this as NOTABUG. Arch Linux ran into the Gnulib test failure associated with this and Bruno Haible agreed that Gnulib should handle this case better [1]. [1] https://lists.gnu.org/r/bug-gnulib/2026-09/msg00068.html
Closing as NOTABUG as requested. Thanks.