Re: Bug#1098694: Crash in agetty due to invalid strncmp call in Trixie

Hello Florian,

thanks for your report.

I'm CC:ing upstream.

* Florian Bach <[email protected]> [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