uname is broken: how do I determine the currently running kernel?

You have upgraded your libc (the most basic system library) and now no program works. To be precise, no dynamically linked program works.

In your particular scenario, rebooting should work. The now-installed libc requires a newer kernel, and if you reboot, you should get that newer kernel.

As long as you still have a running shell, there's often a way to recover, but it can be tricky if you didn't plan for it. If you don't have a shell then usually there's no solution other than rebooting.

Here you may not be able to recover without rebooting, but you can at least easily find out what kernel is running. Just use a way to read /proc/version that doesn't require an external command.

read v </proc/version; echo $v
echo $(</proc/version)               # in zsh/bash/ksh

If you still have a copy of the old libc around, you can run programs with it. For example, if the old libc is in /old/lib and you have executables that work with this old libc in /old/bin, you can run

LD_LIBRARY_PATH=/old/lib /old/lib/ld-linux.so.2 /old/bin/uname

If you have some statically linked binaries, they'll still work. I recommend installing statistically linked system utilities for this kind of problem (but you have to do it before the problem starts). For example, on Debian/Ubuntu/Mint/…, install one or more of busybox-static (collection of basic Linux command line tools including a shell), sash (shell with some extra builtins), zsh-static (just a shell but with quite a few handy tools built in).

busybox-static uname
sash -c '-cat /proc/version'
zsh-static -c '</proc/version'

That appears to be the error glibc throws if it's running on a kernel that is older than what the library is compiled to support. The error message is in the DL_SYSDEP_OSCHECK(FATAL) macro in sysdeps/unix/sysv/linux/dl-osinfo.h

There's a compile time option for this:

--enable-kernel=version
This option is currently only useful on GNU/Linux systems. The version parameter should have the form X.Y.Z and describes the smallest version of the Linux kernel the generated library is expected to support. The higher the version number is, the less compatibility code is added, and the faster the code gets.

So it seems that for some reason, you're running a system with an old kernel but an installed glibc that doesn't support the old kernel any longer. How you got the is hard to tell without information on what system it is, but one might assume that could happen if the library is updated but the kernel isn't.

file seems to show the minimum version required by an executable or a library (but of course you need a working library to run it):

/lib/x86_64-linux-gnu/libc-2.23.so: ELF 64-bit LSB shared object, x86-64, ..., for GNU/Linux 2.6.32, stripped

On my semi-current Debian systems, the required kernel version is 2.6.32 as above on all binaries I checked, which would make it quite unlikely to hit an issue with the kernel version.

Try with this:

cat /proc/version