Crash in fnvlist_lookup_string() in libnvpair

[Binarus]

System information

Type	Version/Name
Distribution Name	Debian
Distribution Version	bookworm
Kernel Version	Linux cerberus 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux
Architecture	amd64
OpenZFS Version	zfs-2.2.6-1~bpo12+3 / zfs-kmod-2.2.6-1~bpo12+3

Describe the problem you're observing

The command sequence shown below leads to a crash that apparently occurs in libnvpair in function fnvlist_lookup_string.

Please note: I have no clue whether all of the commands shown below are needed to trigger the crash. Also, I am not claiming that the command sequence does make any sense. I just encountered the crash during tests and believe that such a crash should not happen even with command sequences that are not sensible.

Describe how to reproduce the problem

Create a pool with name rpool. If it already exists, please make sure that it does not yet contain the datasets rpool/data, rpool/backup and rpool/clone.

Then run the following command sequence:

zfs create rpool/data
zfs snapshot rpool/data@1
zfs snapshot rpool/data@2
zfs snapshot rpool/data@3
zfs send -R rpool/data@3 | zfs receive -F rpool/backup
zfs destroy rpool/backup@2
zfs clone rpool/backup@1 rpool/clone
zfs promote rpool/clone
zfs send -R -I rpool/data@1 rpool/data@3 | zfs receive -F rpool/clone
zfs promote rpool/backup
zfs snapshot rpool/data@4
zfs send -R -I rpool/data@3 rpool/data@4 | zfs receive -F rpool/clone

The last line leads to the crash. The crash happens at the right side of the pipe, in a function in libnvpair that is called by zfs receive.

I'd like to stress again that I really don't know whether there is a shorter way to trigger the crash, and that the command sequence above was just for testing.

Include any warning/errors/backtraces from the system logs

The following output is not from the system logs, but directly from the terminal session. It appears on the terminal when the last line of the command sequence above is executed. I haven't looked into the system logs because I believe that this output is sufficient to analyze the problem.

Of course, I will help with the analysis as far as I can, and provide more logs if needed. Please instruct me what to do, and I'll try my best.

ASSERT at module/nvpair/fnvpair.c:409:fnvlist_lookup_string()
nvlist_lookup_string(nvl, name, &rv) == 0 (0x16 == 0)
  PID: 3001675   COMM: zfs
  TID: 3001675   NAME: zfs
Call trace:
  /lib/x86_64-linux-gnu/libzfs.so.4(libspl_assertf+0x157) [0x7fe222712127]
  /lib/x86_64-linux-gnu/libnvpair.so.3(fnvlist_lookup_string+0x68) [0x7fe2226a10a8]
  /lib/x86_64-linux-gnu/libzfs.so.4(+0x3c290) [0x7fe2226f6290]
  /lib/x86_64-linux-gnu/libzfs.so.4(+0x3dcfd) [0x7fe2226f7cfd]
  /lib/x86_64-linux-gnu/libzfs.so.4(zfs_receive+0xc1) [0x7fe2226f9801]
  zfs(+0x10aa8) [0x5569c2fe9aa8]
  zfs(+0x73a6) [0x5569c2fe03a6]
  /lib/x86_64-linux-gnu/libc.so.6(+0x2724a) [0x7fe2224c624a]
  /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7fe2224c6305]
  zfs(+0x74e1) [0x5569c2fe04e1]
./zfs-test-clone: line 57: 3001674 Broken pipe             zfs send -R -I rpool/data@3 rpool/data@4
     3001675 Aborted                 | zfs receive -F rpool/clone

[Binarus]

In the meantime, I have repeated the test with OpenZFS 2.2.7. The outcome was the same (except that the memory addresses were different, which I would have expected).