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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 7 Oct 2022 20:52:44 +0900 From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> To: Dominique Martinet <asmadeus@...ewreck.org>, Alexander Viro <viro@...iv.linux.org.uk> Cc: Christian Schoenebeck <linux_oss@...debyte.com>, Eric Van Hensbergen <ericvh@...il.com>, Latchesar Ionkov <lucho@...kov.net>, syzbot <syzbot+8b41a1365f1106fd0f33@...kaller.appspotmail.com>, v9fs-developer@...ts.sourceforge.net, syzkaller-bugs@...glegroups.com, netdev@...r.kernel.org, linux-fsdevel <linux-fsdevel@...r.kernel.org> Subject: Re: [PATCH v2] 9p/trans_fd: perform read/write with TIF_SIGPENDING set On 2022/10/07 10:40, Dominique Martinet wrote: > Tetsuo Handa wrote on Sun, Sep 04, 2022 at 09:27:22AM +0900: >> On 2022/09/04 8:39, Dominique Martinet wrote: >>> Is there any reason you spent time working on v2, or is that just >>> theorical for not messing with userland fd ? >> >> Just theoretical for not messing with userland fd, for programs generated >> by fuzzers might use fds passed to the mount() syscall. I imagined that >> syzbot again reports this problem when it started playing with fcntl(). >> >> For robustness, not messing with userland fd is the better. ;-) > > By the way digging this back made me think about this a bit again. > My opinion hasn't really changed that if you want to shoot yourself in > the foot I don't think we're crossing any priviledge boundary here, but > we could probably prevent it by saying the mount call with close that fd > and somehow steal it? (drop the fget, close_fd after get_file perhaps?) > > That should address your concern about robustess and syzbot will no > longer be able to play with fcntl on "our" end of the pipe. I think it's > fair to say that once you pass it to the kernel all bets are off, so > closing it for the userspace application could make sense, and the mount > already survives when short processes do the mount call and immediately > exit so it's not like we need that fd to be open... > > > What do you think? I found that pipe is using alloc_file_clone() which allocates "struct file" instead of just incrementing "struct file"->f_count. Then, can we add EXPORT_SYMBOL_GPL(alloc_file_clone) to fs/file_table.c and use it like struct file *f; ts->rd = fget(rfd); if (!ts->rd) goto out_free_ts; if (!(ts->rd->f_mode & FMODE_READ)) goto out_put_rd; f = alloc_file_clone(ts->rd, ts->rd->f_flags | O_NONBLOCK, ts->rd->f_op); if (IS_ERR(f)) goto out_put_rd; fput(ts->rd); ts->rd = f; ts->wr = fget(wfd); if (!ts->wr) goto out_put_rd; if (!(ts->wr->f_mode & FMODE_WRITE)) goto out_put_wr; f = alloc_file_clone(ts->wr, ts->wr->f_flags | O_NONBLOCK, ts->wr->f_op); if (IS_ERR(f)) goto out_put_wr; fput(ts->wr); ts->wr = f; from p9_fd_open() for cloning "struct file" with O_NONBLOCK flag added? Just an idea. I don't know whether alloc_file_clone() arguments are correct...
Powered by blists - more mailing lists