#13 ATFTPD crashes when requested a non-existent file

[Michael Dmitry]

Using the latest atftpd, whenever a client sends a request to get a file that is non existent, the service crashes.
No error logs are shown in the var/log file, it just stops logging
is this a know issue with the latest build?

[Andi]

Hi,
can you please provide a bit more information? Do you use a packaged atftpd, if 'yes', which distribution? How is atftpd started (systemd socket activation or xinetd)? What if you run the server in debug mode? Perhaps directly from the command line?

I tested here on Debian testing and anything seems to work fine:

$ atftp
tftp> connect localhost
tftp> get d-i/n-a/bootnetx64.efi
Overwrite local file [y/n]? y
tftp> get nonexistent
tftp: error received from server <file not="" found="">
tftp: aborting
tftp> quit</file>

journalctl -f -u atftpd
Aug 17 11:51:18 atftpd[2277791]: Advanced Trivial FTP server started (0.7.5)
Aug 17 11:51:18 atftpd[2277791]: started by inetd
Aug 17 11:51:18 atftpd[2277791]: logging level: 7
Aug 17 11:51:18 atftpd[2277791]: directory: /var/lib/tftpboot/
Aug 17 11:51:18 atftpd[2277791]: user: nobody.nogroup
Aug 17 11:51:18 atftpd[2277791]: log file: syslog
Aug 17 11:51:18 atftpd[2277791]: not forcing to listen on local interfaces.
Aug 17 11:51:18 atftpd[2277791]: server timeout: 20
Aug 17 11:51:18 atftpd[2277791]: tftp retry timeout: 1
Aug 17 11:51:18 atftpd[2277791]: maximum number of thread: 100
Aug 17 11:51:18 atftpd[2277791]: option timeout: enabled
Aug 17 11:51:18 atftpd[2277791]: option tzise: enabled
Aug 17 11:51:18 atftpd[2277791]: option blksize: enabled
Aug 17 11:51:18 atftpd[2277791]: option windowsize: enabled
Aug 17 11:51:18 atftpd[2277791]: option multicast: disabled
Aug 17 11:51:18 atftpd[2277791]: address range: 239.255.0.0-255
Aug 17 11:51:18 atftpd[2277791]: port range: 1758
Aug 17 11:51:18 atftpd[2277791]: socket may listen on any address, including broadcast
Aug 17 11:51:18 atftpd[2277791]: Creating new socket: :::46308
Aug 17 11:51:18 atftpd[2277791]: Serving d-i/n-a/bootnetx64.efi to ::1:41355
Aug 17 11:51:18 atftpd[2277791]: End of transfer
Aug 17 11:51:18 atftpd[2277791]: Server thread exiting
Aug 17 11:51:26 atftpd[2277791]: socket may listen on any address, including broadcast
Aug 17 11:51:26 atftpd[2277791]: Creating new socket: :::48549
Aug 17 11:51:26 atftpd[2277791]: Serving nonexistent to ::1:38747
Aug 17 11:51:26 atftpd[2277791]: File /var/lib/tftpboot/nonexistent not found
Aug 17 11:51:26 atftpd[2277791]: Server thread exiting
Aug 17 11:51:46 atftpd[2277791]: atftpd terminating after 20 seconds
Aug 17 11:51:46 atftpd[2277791]: Load measurements:
Aug 17 11:51:46 atftpd[2277791]: User: 0.000s Sys: 0.000s
Aug 17 11:51:46 atftpd[2277791]: Total: 28.057s CPU: 0.214%
Aug 17 11:51:46 atftpd[2277791]: Time between connections:
Aug 17 11:51:46 atftpd[2277791]: Min: 8.038s Max: 8.038s
Aug 17 11:51:46 atftpd[2277791]: Thread stats:
Aug 17 11:51:46 atftpd[2277791]: simultaneous threads: 1
Aug 17 11:51:46 atftpd[2277791]: number of servers: 1
Aug 17 11:51:46 atftpd[2277791]: number of aborts: 0
Aug 17 11:51:46 atftpd[2277791]: number of errors: 1
Aug 17 11:51:46 systemd[1]: atftpd.service: Deactivated successfully.
Aug 17 11:51:46 atftpd[2277791]: number of files sent: 1
Aug 17 11:51:46 atftpd[2277791]: number of files received: 0
Aug 17 11:51:46 atftpd[2277791]: Main thread exiting

[Grzegorz Gutowski]

Hi,
I've found the same behavior on ubuntu jammy.
After some debugging I've found this:

Strncpy(tftphdr->th_msg, tftp_errmsg[err_code], buffer_size - 4);

in line 171 of tftp_io.c

The definition of tftphdr in /usr/include/arpa/tftp.h is as follows:

struct  tftphdr {
        short   th_opcode;                      /* packet type */
        union {
                char    tu_padding[3];          /* sizeof() compat */
                struct {
                        union {
                                unsigned short  tu_block;       /* block # */
                                short   tu_code;                /* error code */
                        } __attribute__ ((__packed__)) th_u3;
                        char tu_data[0];        /* data or error string */
                } __attribute__ ((__packed__)) th_u2;
                char    tu_stuff[0];            /* request packet stuff */
        } __attribute__ ((__packed__)) th_u1;
} __attribute__ ((__packed__));

#define th_block        th_u1.th_u2.th_u3.tu_block
#define th_code         th_u1.th_u2.th_u3.tu_code
#define th_stuff        th_u1.tu_stuff
#define th_data         th_u1.th_u2.tu_data
#define th_msg          th_u1.th_u2.tu_data

I suppose that:

char tu_data[0];

disagrees with range checking in Strncpy.

Changing line 171 to:

Strncpy(buffer + 4, tftp_errmsg[err_code], buffer_size - 4);

fixes the issue for me.

[Andi]

Hi,
thanks for the report and patch. I have to investigate, as soon I find some available time slot.

[Andi]

Hm, seems to be Ubuntu specific, still not reproducible here on Debian. I'm going to install jammy and try to find the difference. Ubuntu bug : https://bugs.launchpad.net/ubuntu/+source/atftp/+bug/1989816

[Martin Dummer]

I cannot confirm the problem either. Requesting non-existent files from atftpd happens very often during pxeboot, so a serious error like this would be detected quickly.

[Grzegorz Gutowski]

Well, this is exactly how I found out.
The default install on jammy uses systemd sockets and restarts atftpd daemon after each segfault.
This might hide the problem for some time.

[Andi]

I can confirm the issue on jammy. However, as far as I can tell, it's the same code. I did not investigate it in detail, but it looks like it's a matter of compiler flags applied, which causes the issue.

[l2fl2f]

On Ubuntu 22.04: 0.7.git20210915-4 crashes unable to start any client

[Eduardo Barretto]

By default Ubuntu compile packages with LTO enabled, which I think Debian is not yet using.
There's two course of actions, either we disable it on our Deb, or upstream can evaluate if they want to have this compile flag enabled by default and fix the issues in code (something like the mentioned fix above).