#1108549 procps: w segfaults when run as non-root user

Package:
procps
Source:
procps
Description:
/proc file system utilities
Submitter:
Andrew Bower
Date:
2025-07-30 12:21:01 UTC
Severity:
normal
Tags:
#1108549#5
Date:
2025-06-30 22:36:59 UTC
From:
To:
Dear Maintainer,

Running 'w' as a non-root user on i386 segfaults:

$ gdb w
GNU gdb (Debian 16.3-1) 16.3
[...]
This GDB was configured as "i686-linux-gnu".
[...]
(gdb) run
Starting program: /usr/bin/w
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
 23:21:56 up 4 min,  0 users,  load average: 0.74, 1.06, 0.52
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT

Program received signal SIGSEGV, Segmentation fault.
Download failed: Invalid argument.  Continuing without source file ./src/w.c.
0x00401979 in main (argc=<optimized out>, argv=<optimized out>) at src/w.c:1130
warning: 1130   src/w.c: No such file or directory

This reliably reproduces in the failing environment but not when run as root or
on an amd64 host with kernel 6.12.27-1.

Thanks!

#1108549#10
Date:
2025-07-23 21:31:47 UTC
From:
To:
Hi,
sessions_list is then also used, undefined. This part of the bug is
therefore not architecture-specific even if the crash is not generally
reproduced yet.

I attach a patch that fixes the segfault to advance the discussion.
Personally I think this ought to be fixed for trixie.

However, we are unfortunately not out of the woods: elogind is running
on this host and root is able to see the sessions. So is 'who' as
non-root with the newly libsystemd-ised coreutils:

$ w
 21:26:33 up 10 min,  0 users,  load average: 0.00, 0.10, 0.12
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
Segmentation fault
$ debian/procps/usr/bin/w # with patch
 21:26:42 up 11 min,  0 users,  load average: 0.00, 0.10, 0.12
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
$ sudo w
Please touch the FIDO authenticator.
 21:26:50 up 11 min,  1 user,  load average: 0.64, 0.23, 0.16
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
ajb85    pts/0    -                21:26    0.00s  0.03s  0.12s sudo w
$ sudo debian/procps/usr/bin/w # with patch
 21:26:54 up 11 min,  1 user,  load average: 0.59, 0.23, 0.16
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
ajb85    pts/0    -                21:26    0.00s  0.02s  0.06s sudo debian/procps/usr/bin/w
$ who
ajb85    seat0        2025-07-23 21:17
ajb85    tty1         2025-07-23 21:17

This secondary issue could of course be an elogingd problem so I am
copying this message to the elogind package tracker for awareness.

Thanks!

#1108549#15
Date:
2025-07-24 18:15:12 UTC
From:
To:
Control: tag -1 + patch
[...]

Done a bit more digging. A number of issues - sorry, I don't have time
to split them out into appropriate bugs right now. The first is
definitely for procps:

1. Unitialised 'sessions' variable is a a bug on all systems which leads
   to a segfault on some. I'm now tagging this bug as having a patch.

2. elogind not being queried. Is this an elogind issue? Should it give a
   different answer to sd_booted() or is this the wrong way to detect the
   seat management capability? 'who' does not have this problem - it
   somehow queries elogind anyway.

procps then resorts to utmp.

3. Some (vc) sessions not reported unless running as root, but the non-root
   user could read utmp. 'who' does not have this problem but then it
   probably didn't resort to reading utmp (see 2 above).

4. Virtual console sessions reported as pts/# instead of tty# in utmp - I
   guess we can blame login for that but we're off on a tangent now: 1-3 are
   more important to sort out.

#1108549#26
Date:
2025-07-27 22:08:56 UTC
From:
To:
In the absence of any other fixes, my patch for this still stands.
But...

Removing the call to sd_booted() and just using the result of
sd_get_sessions() is sufficient. I get the correct outcome in this case.

Unfortunately we don't then get any runtime fallback to utmp but my
guess is working elogind support would be preferred (and should be fixed
for trixie).

I am not proposing a patch here because it needs attention from someone
more familiar with the relevant components.

My hunch is that the best plan for trixie is to go straight to calling
sd_get_sessions() and not testing sd_booted(). This would then supersede
the patch for (1).
sudo itself.

#1108549#31
Date:
2025-07-28 07:28:17 UTC
From:
To:
Remove sd_booted() check
if sd_get_sessions()
  < 0 && != ENOENT: error
  > 0: show sessions
  default: fallback to utmp

This should deal with:
  1. systemd and elogind with some login sessions: show sessions
  2. neither systemd nor elogind: fallback to utmp reading
  3. systemd and elogind with no sessions: show nothing, as now, but via
     fallback utmp route with no practical difference.

I don't see a downside from this approach.

#1108549#36
Date:
2025-07-28 09:34:55 UTC
From:
To:
Yep, that makes sense. Upstream have this set to 0 so it got missed.
elogind always returns 0 for sd_booted().
Maybe who doesn't look at sd_booted() and directly goes to
sd_get_sessions()?
And everything else beyond this is issues with utmp handling.

Also
$ who
ajb85    seat0        2025-07-23 21:17
ajb85    tty1         2025-07-23 21:17
is the wrong output as its not checking for user sessions with
sd_session_get_class()

 - Craig

#1108549#41
Date:
2025-07-28 10:07:12 UTC
From:
To:
I think this is the correct way too. I'll double check that 0 user path
because it looks odd, but its probably doing the right thing.

 - Craig

#1108549#46
Date:
2025-07-28 17:16:22 UTC
From:
To:
Hi Craig,

Thanks for reviewing my suggestions!

A slight tweak to this algorithm might allay anxiety about the 0
sessions case, whereby we reintroduce the sd_booted() check in a
different place to create an alternative path:

  if sd_get_sessions()
    < 0 && != ENOENT: error
    > 0 || sd_booted(): show sessions
    default: fallback to utmp

In this case if systemd is running then the utmp fallback is never
attempted - this results in no ambiguity about the outcome in this more
predictable scenario.

(N.B. would also need to zero out the session count in case of ENOENT)

What do you think of this variation?

Andrew

#1108549#51
Date:
2025-07-28 22:55:16 UTC
From:
To:
See https://salsa.debian.org/debian/procps/-/merge_requests/9 for my
implementation of this approach.

#1108549#58
Date:
2025-07-30 12:19:12 UTC
From:
To:
We believe that the bug you reported is fixed in the latest version of
procps, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1108549@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Craig Small <csmall@debian.org> (supplier of updated procps package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Wed, 30 Jul 2025 21:58:40 +1000
Source: procps
Architecture: source
Version: 2:4.0.4-9
Distribution: unstable
Urgency: medium
Maintainer: Craig Small <csmall@debian.org>
Changed-By: Craig Small <csmall@debian.org>
Closes: 1108549
Changes:
 procps (2:4.0.4-9) unstable; urgency=medium
 .
   [ Craig Small ]
   * d/changelog: Fix number for skill bug
 .
   [ Andrew Bower ]
   * Initialise sessions variable in w. (Closes: #1108549)
   * d/patches: get sessions even if !sd_booted()
Checksums-Sha1:
 fc0381a50c53b2520c68d75f242370cc730c17e4 2124 procps_4.0.4-9.dsc
 d0129f2f423db17a6012bf90e17a0f3e1f25274e 45932 procps_4.0.4-9.debian.tar.xz
 85a9269c973bcc738c1f5aa44e9d6885b44be30e 7227 procps_4.0.4-9_amd64.buildinfo
Checksums-Sha256:
 0ea43605b8d5d7ac4306af0dcd2d01e237cbaba6603b0cf248dd7cfd4364ac7a 2124 procps_4.0.4-9.dsc
 4821ca009f83b05522bc97ddac82661898938323ef0808416bca7830ce19bd97 45932 procps_4.0.4-9.debian.tar.xz
 f8b0e626e6bd21c1e64050b6c7c33a81ad1773f9c67afdfab4a12ad4d1641a34 7227 procps_4.0.4-9_amd64.buildinfo
Files:
 289d1b94b96c24ae735e175c8c267955 2124 admin optional procps_4.0.4-9.dsc
 0ca4994349f1c4b5e089073736de21d4 45932 admin optional procps_4.0.4-9.debian.tar.xz
 7ad1b7532c0a034309246ac6db4ba165 7227 admin optional procps_4.0.4-9_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEXT3w9TizJ8CqeneiAiFmwP88hOMFAmiKCVAACgkQAiFmwP88
hOMqwA/+MdZPLHvvoNwZeJxisLJ4qG/JaNvrWDwnWK/vzt8ehYuv/MnHcuG7kx67
zuET4IYpNLWe6WRSXrJPn3sinpsDIplT3tsMSm8XOCNvYxQLYHle7F4at84zHYjF
CHRMRzpNOqtY8XCZ5jiGElmQxCntJBY+eV2IcOv8z6UIIKY3cYc/5UDJmENz2NZ4
DOzAMomS6eX1qPtGizvkiba0Yn5VnnfhErvA1O3TjtW22gqYZbYR/PWAyh7S8wEL
g6Gk4IGhhc2bf0xqe80dxVvv2op+4HwwfFSdrfgCRhOVbPbyAXx+DNb56Yw8q2Ra
zuyVIy+XEgEn3Ms5K0oZk1nPQKm5r5eA6XWsmdCxW/qTkKmBMsciKwVQ69h1jbye
vDCnBA8F9woFRLmIr/+9wQCJs4NSt34tTGfjm7Eblb2YI4j4Cnb4d2l0Uh+cJlVQ
bF/kYyHBwyhe6/57LgCFuahvbiLRqS37rc9dM1592gBn/0/1aNfppnaU7Q42lZ5U
tTJU6ygONgkge3pQ9Mt2zQ/Uf5YJz247q7v3Zcet0OIMOmy8ypagSE5xcm37dHqb
FsAxNFkgd8K2CSCVCPB8yqS1uod0m/TfcZis/5/ZyIDIAm7ICtbHyIFJtjrKM4W7
JI6jVzbJgHxkypqPfv+mg7LJr2dZpl8M/Xe9m16st49iLp+wc1o=
=Nwxj
-----END PGP SIGNATURE-----