bpf kernel code leaks internal error codes to userspace

[Lennart Poettering <mzxreary@0pointer.net>]

Hi!

It seems that the bpf code in the kernel sometimes leaks
kernel-internal error codes, i.e. those from include/linux/errno.h
into userspace (as opposed to those from
include/uapi/asm-generic/errno.h which are public userspace facing
API).

According to the comments from that internal header file: "These
should never be seen by user programs."

Specifically, this is about ENOTSUPP, which userspace simply cannot
handle, there's no error 524 defined in glibc or anywhere else.

We ran into this in systemd recently:

https://github.com/systemd/systemd/issues/32170#issuecomment-2076928761

(a google search reveals others were hit by this too)

We commited a work-around for this for now:

https://github.com/systemd/systemd/pull/33067

But it really sucks to work around this in userspace, this is a kernel
internal definition after all, conflicting with userspace (where
ENOTSUPP is just an alias for EOPNOTSUPP), hence not really fixable.

ENOSUPP is kinda useless anyway, since EOPNOTSUPP is pretty much
equally expressive, and something userspace can actually handle.

Various kernel subsystems have been fixed over the years in similar
situations. For example:

https://patchwork.kernel.org/project/linux-wireless/patch/20231211085121.3841b71c867d.Idf2ad01d9dfe8d6d6c352bf02deb06e49701ad1d@changeid/

or

https://patchwork.kernel.org/project/linux-media/patch/af5b2e8ac6695383111328267a689bcf1c0ecdb1.1702369869.git.sean@mess.org/

or

https://patchwork.ozlabs.org/project/linux-mtd/patch/20231129064311.272422-1-acelan.kao@canonical.com/

I think BPF should really fix that, too.

Or if you insist on leaking internals to userspace then please move
the definition to the public "uapi" headers, but yikes you are in for
some pain then given the conflicting userspace definitions.

Lennart