Hello Florian,
thanks for your report.
I'm CC:ing upstream.
* Florian Bach <Leseratte10@xxxxxxxxxxx> [250222 21:39]:
> I am running Debian Trixie in a Proxmox VM. I noticed that on the login
> screen there are errors of agetty crashing with a segfault. There's nothing
> special about the VM, it's a blank VM running the daily cloud images of
> Debian Trixie.
>
> The VM is running Linux 6.12.12-1 with util-linux 2.40.4-3 and libc6 2.40-7.
Could you provide some more info and also try something:
1) is this on amd64?
2) which terminal is this? tty1 or something else?
3) whats your kernel command line?
4) which image did you use exactly?
5) could you try util-linux 2.41-rc1 from experimental?
> I debugged this with ltrace and believe I found the error, or at least some
> invalid behaviour.
>
> In agetty.c in the debian sources for util-linux, right at the end of the
> function parse_args, there's code that tries to figure out the terminal name
> using a call to get_terminal_name. For some reason, this function call seems
> to fail on my machine and it prints the error "could not get terminal name".
>
> This causes it to set &op->tty to NULL, and unfortunately, a couple lines
> later, that variable is used in a strncmp call, causing it to crash.
>
> Here's the corresponding lines from the ltrace log:
>
> strtok(nil, ",") = nil
> free(0x557c64154be0) = <void>
> strcmp("-", "-") = 0
Looks like we're in term-utils/agetty.c line 929ff, which has a
comment:
/* resolve the tty path in case it was provided as stdin */
Which seems to be the default code path on systemd systems.
> isatty(0) = 0
> isatty(1) = 0
> isatty(2) = 0
This must have been get_terminal_stdfd from lib/ttyutils.c
> dcgettext(nil, "could not get terminal name: %d", 5) = "could not get
> terminal name: %d"
[..]
I think the relevant part would be seeing what /proc/<pid>/fd/0 ,
/proc/<pid>/fd/1 , /proc/<pid>/fd/2 point to.
> Upload at a filehoster and send the link in response to this bug report?
Attaching should be fine, possibly compressed. Probably an strace
log could be more insightful than the ltrace log.
> Unfortunately, I was not yet able to figure out why on my machine the code
> seems to run into this code path with the "could not get terminal name"
> warning.
> But nevertheless, it's a valid code path, and it's just a warning
> not an error, so the code that comes after it should be able to handle this
> without crashing.
Looks like commit 47831cc02ac0d71c335caecef1753f4c8861277c did not
take this into account fully. get_terminal_name resets *name to
NULL, and I think then op->tty ends up being NULL.
Related: https://github.com/util-linux/util-linux/issues/1546#issuecomment-1005855533
Chris
