From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomas Bortoli Subject: Re: [PATCH] 9p: fix NULL pointer dereferences Date: Thu, 26 Jul 2018 16:32:15 +0200 Message-ID: References: <20180726081049.10527-1-tomasbortoli@gmail.com> <20180726081727.GA6699@nautica> <20180726094849.GA18334@nautica> <20180726142109.GA4235@nautica> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Dmitry Vyukov , David Miller , v9fs-developer@lists.sourceforge.net, netdev , LKML , syzkaller To: Dominique Martinet Return-path: In-Reply-To: <20180726142109.GA4235@nautica> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On 07/26/2018 04:21 PM, Dominique Martinet wrote: > Tomas Bortoli wrote on Thu, Jul 26, 2018: >>> But I think trans=fd allows NULL addr today, no? >> >> How ? > > Just using the mount syscall with a NULL dev_name? I haven't checked > this syzcaller reproducer but it's probably what it does. > > p9_fd_create doesn't use 'addr' at all so it's safe to create a 9p mount > for trans=fd with no device name, as Dmitry pointed out > mmh, ok. > >>> On the other hand, virtio, rdma and xen all have the same problem, so >>> Thomas, please fix them instead :) >> >> So just by patching v9fs_mount ? > > If we want to preserve the current behaviour for trans=fd (and I don't > see why not) we just have to patch all the transports that use the > device, that is all .create functions but p9_fd_create() > > Basically exactly what you did, just for a few more functions - I > apparently was a little bit too optimistic thinking we could share > this check. > Does v9fs_mount() knows the transport ahead? Because in that case it'd be possible to check if addr!=NULL && trans!=fd then return error Otherwise, patching all the .create, ok.