honggfuzz seems to pass files with no hard links

[evverx]

Trying to figure out why some binaries didn't get past a certain point with honggfuzz but were fuzzed with AFL++ I noticed that honggfuzz passed /dev/fd/* pointing to temporary files that had been removed before the binaries were run and it led to those files being rejected by the binaries. stat -L ___FILE___ shows that __FILE__ has no hard links:

$ honggfuzz -v -Q -i INPUT -o OUTPUT -N 1 -- /bin/stat -L ___FILE___
Start time:'2022-06-27.01.58.23' bin:'/bin/stat', input:'INPUT', output:'OUTPUT', persistent:false, stdin:false, mutation_rate:5, timeout:1, max_runs:1, threads:1, minimize:false, git_commit:380cf14962c64e3fa902d9442b6c6513869116ed
[2022-06-27T01:58:23+0000][W][51144] input_getDirStatsAndRewind():114 No usable files in the input directory 'INPUT'
Entering phase 1/3: Dry Run
Launched new fuzzing thread, no. #0
[2022-06-27T01:58:23+0000][W][51145] input_getNext():129 No useful files in the input directory
Entering phase 2/3: Switching to the Feedback Driven Mode
Entering phase 3/3: Dynamic Main (Feedback Driven Mode)
  File: /dev/fd/1021
  Size: 5         	Blocks: 8          IO Block: 4096   regular file
Device: 1h/1d	Inode: 76          Links: 0
Access: (0777/-rwxrwxrwx)  Uid: ( 1000/ vagrant)   Gid: ( 1000/ vagrant)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2022-06-27 01:58:23.017769470 +0000
Modify: 2022-06-27 01:58:23.017769470 +0000
Change: 2022-06-27 01:58:23.017769470 +0000
 Birth: 2022-06-27 01:58:23.017769470 +0000
Terminating thread no. #0, left: 0
Summary iterations:2 time:1 speed:2 crashes_count:0 timeout_count:0 new_units_added:0 slowest_unit_ms:8 guard_nb:0 branch_coverage_percent:0 peak_rss_mb:6

I wonder if it would be possible to remove those temporary files after binaries stop/crash?

[yinfeidi]

Also, I found some binaries parsing /dev/fd/* files resulting in faults and I would like to modify the source code on the temporary file location. If you have some ideas, offer me plz.

[robertswiecki]

Those files are essentially memfd objects, so they never exist on the FS.

We could maybe try to use linkat2(AT_EMPTY_PATH) to link those files to some tmpfs.

But, do you know the reason an application wants to read number of links to a file before process? Any specific examples?

[evverx]

Those files are essentially memfd objects, so they never exist on the FS.

Looking at

honggfuzz/libhfcommon/files.c

Lines 97 to 107 in 847492c

	int files_writeBufToTmpFile(const char* dir, const uint8_t* buf, size_t fileSz, int flags) {
	char template[PATH_MAX];
	snprintf(template, sizeof(template), "%s/hfuzz.XXXXXX", dir);
	int fd = mkostemp(template, flags);
	if (fd == -1) {
	PLOG_W("mkostemp('%s') failed", template);
	return -1;
	}
	if (unlink(template) == -1) {
	PLOG_W("unlink('%s')", template);
	}

I thought honggfuzz removed real files before pointing fuzz targets to them. It could be that I looked at the wrong part of the code though.

Any specific examples?

sd-journal refuses to open files like that: https://github.com/systemd/systemd/blob/0e6858232387050b2bff15365043914e4c764d7c/src/libsystemd/sd-journal/journal-file.c#L511-L513.

[robertswiecki]

It's a shared mem created here -

honggfuzz/fuzz.c

Line 496 in 847492c

if (!(run.dynfile->data = files_mapSharedMem(hfuzz->mutate.maxInputSz, &(run.dynfile->fd),

But the effect is the same, it doesn't have presence on the FS.

[robertswiecki]

Well, if you change the 4th param of this call to true, you'll probably get what you want. If you'd like to surround it with some flag, I'll be happy to review w PR.