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
| ||
|
Message-ID: <Yz+Di8tJiyPPJUaK@codewreck.org> Date: Fri, 7 Oct 2022 10:40:27 +0900 From: Dominique Martinet <asmadeus@...ewreck.org> To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> 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 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? (either way would be for 6.2, the patch is already good enough as is for me) -- Dominique
Powered by blists - more mailing lists