crashed in the user namespace created by an unprivileged process

[Lanius-collaris]

version

tcpdump version 4.99.5
libpcap version 1.10.5 (with TPACKET_V3)
OpenSSL 3.2.6 30 Sep 2025
64-bit build, 64-bit time_t

Fedora Linux 42
glibc 2.41

steps to reproduce

$ unshare -U -r -n
$ ip link set lo up
$ tcpdump -Z root -i lo -w /tmp/netns1.pcap

• This is not a security issue (See first line).

[infrastation]

Is this tcpdump 4.99.5 with Fedora patches? Does the same reproduce for 4.99.6 and the current master branch?

[Lanius-collaris]

Is this tcpdump 4.99.5 with Fedora patches?

Yes.
https://src.fedoraproject.org/rpms/tcpdump/blob/f42/f/tcpdump.spec#_21

Does the same reproduce for 4.99.6 and the current master branch?

The same steps don't reproduce segmentation fault when running the current master branch ( it can save PCAP files without -Z ).

[guyharris]

Do you have a stack trace for this crash?

[Lanius-collaris]

Do you have a stack trace for this crash?

https://retrace.fedoraproject.org/faf/reports/1359384/
Could getpwnam() cause a segmentation fault?

[guyharris]

Could getpwnam() cause a segmentation fault?

Yes, if either 1) it's passed a null or otherwise invalid pointer for the user name argument or 2) there's a bug in the system library. If it's not 1), it's 2), and I suspect it's not 1), i.e. it's not a tcpdump bug, it's a bug in the Fedora library. If it's 1), but this is a Fedora-modified tcpdump, and their modifications caused a null or otherwise invalid pointer to be passed to getpwent(), that's also a Fedora bug.

[guyharris]

Yes, if either 1) it's passed a null or otherwise invalid pointer for the user name argument or 2) there's a bug in the system library. If it's not 1), it's 2), and I suspect it's not 1),

Well... tcpdump segv if -Z and -w is specified:

There is currently a bug in tcpdump causing it to segfault on Noble machines and newer.

This is because of a bad interaction with d/p/drop-privs-only-if-non-root.diff
where using -Z root sets username to NULL, causing a null pointer dereference and subsequent segmentation fault.

and it provides a fix.

The main branch code and the 1.10.6 code is significantly different, and will not get to the getpwnam() call if the user name is null, so the problem may be that...

If it's 1), but this is a Fedora-modified tcpdump, and their modifications caused a null or otherwise invalid pointer to be passed to getpwent(), that's also a Fedora bug.

...this is the case.

Debian has a patch to drop privileges after opening a savefile and, as it notes, it's from Fedora, so that seems to be the issue here - it probably is a Fedora bug. Perhaps the Debian fix to the bug has been applied to Fedora; to quote the Debian fix's commit message:

Rodney Dawes reports that the patch from upstream PR #812 that we picked
up in drop-privs-only-if-non-root.diff doesn't play nice with the other
patch from Fedora to drop privileges *before* opening savefiles as it
leads to calling getpwnam() with a NULL argument.

Meanwhile, we should see if we need to change anything in order to drop privileges before opening output files and, if so, make sure it's Done Right.

[guyharris]

The comment added for the "drop privileges after opening a savefile" patch is

	/* If user is running tcpdump as root and wants to write to the savefile,
	 * we will check if -C is set and if it is, we will drop root
	 * privileges right away and consequent call to>pcap_dump_open()
	 * will most likely fail for the first file. If -C flag is not set we
	 * will create file as root then change ownership of file to proper
	 * user(default tcpdump) and drop root privileges.
	 */

I'm guessing that means "if you run tcpdump as root and have it be able to write to any directory to which root can write, i.e. if part of your rationale for running as root is to dump a capture file into a root-only directory, we have to support that, but we'd like not to have tcpdump run with root privileges while it's capturing and processing packets". I guess that's so that packet processing isn't done as root.

The check for -C is to check whether you're writing a sequence of capture files, based on file size; if that's the case, you can't drop root until you've opened the last capture file, but you don't necessarily know when that happens, so you're out of luck.

I'm not sure this is really an interesting use case, especially given that it has to do that weird corner-case hack, and it's a case of "I want it to have root privileges to write out to files in a directory that requires root privileges but I don't want it to have root privileges after that" (yeah, but what about other programs where somebody might want it to have root file system privileges until they don't want it to have them?), so my inclination is not to pick up the Fedora/Debian change, which means that our version doesn't have an issue with a null pointer being passed to getpwnam().

[guyharris]

See also #448, #388, and my comment on this whole "root when creating files but not at other times" thing #388 (comment)

[guyharris]

See also this followup: #388 (comment)