linux-kernel - Re: [syzbot] [netfs?] INFO: task hung in netfs_unbuffered_write

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250323210251.GD14883@redhat.com>
Date: Sun, 23 Mar 2025 22:02:52 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: syzbot <syzbot+62262fdc0e01d99573fc@...kaller.appspotmail.com>,
	brauner@...nel.org, dhowells@...hat.com, jack@...e.cz,
	jlayton@...nel.org, kprateek.nayak@....com,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	netfs@...ts.linux.dev, swapnil.sapkal@....com,
	syzkaller-bugs@...glegroups.com, viro@...iv.linux.org.uk
Subject: Re: [syzbot] [netfs?] INFO: task hung in netfs_unbuffered_write_iter

Prateek, Mateusz, thanks for your participation!

On 03/23, Mateusz Guzik wrote:
>
> On Sun, Mar 23, 2025 at 8:47 PM Oleg Nesterov <oleg@...hat.com> wrote:
> >
> > OK, as expected.
> >
> > Dear syzbot, thank you.
> >
> > So far I think this is another problem revealed by aaec5a95d59615523db03dd5
> > ("pipe_read: don't wake up the writer if the pipe is still full").
> >
> > I am going to forget about this report for now and return to it later, when
> > all the pending pipe-related changes in vfs.git are merged.
> >
>
> How do you ask syzbot for all stacks?

Heh, I don't know.

> The reproducer *does* use pipes, but it is unclear to me if they play
> any role here

please see the reproducer,

	https://syzkaller.appspot.com/x/repro.c?x=10d6a44c580000

  res = syscall(__NR_pipe2, /*pipefd=*/0x400000001900ul, /*flags=*/0ul);
  if (res != -1) {
    r[2] = *(uint32_t*)0x400000001900;
    r[3] = *(uint32_t*)0x400000001904;
  }

then

  res = syscall(__NR_dup, /*oldfd=*/r[3]);
  if (res != -1)
    r[4] = res;

so r[2] and r[4] are the read/write fd's.

then later

   memcpy((void*)0x400000000280, "trans=fd,", 9);
   ...
   memcpy((void*)0x400000000289, "rfdno", 5);
   ...
   sprintf((char*)0x40000000028f, "0x%016llx", (long long)r[2]);
   ...
   memcpy((void*)0x4000000002a2, "wfdno", 5);
   ...
   sprintf((char*)0x4000000002a8, "0x%016llx", (long long)r[4]);
   ...
   syscall(__NR_mount, /*src=*/0ul, /*dst=*/0x400000000000ul,
           /*type=*/0x400000000040ul, /*flags=*/0ul, /*opts=*/0x400000000280ul);

so this pipe is actually used as "trans=fd".

> -- and notably we don't know if there is someone stuck
> in pipe code, resulting in not waking up the reported thread.

Yes, I am not familiar with 9p or netfs, so I don't know either.

Oleg.