linux-stable.git/net/9p, branch v6.3

9p/xen : Fix use after free bug in xen_9pfs_front_remove due to race condition

2023-04-02T01:00:31+00:00

In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring
to init priv->rings and bound &ring->work with p9_xen_response.

When it calls xen_9pfs_front_event_handler to handle IRQ requests,
it will finally call schedule_work to start the work.

When we call xen_9pfs_front_remove to remove the driver, there
may be a sequence as follows:

Fix it by finishing the work before cleanup in xen_9pfs_front_free.

Note that, this bug is found by static analysis, which might be
false positive.

CPU0                  CPU1

                     |p9_xen_response
xen_9pfs_front_remove|
  xen_9pfs_front_free|
kfree(priv)          |
//free priv          |
                     |p9_tag_lookup
                     |//use priv->client

Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend")
Signed-off-by: Zheng Wang 
Reviewed-by: Michal Swiatkowski 
Signed-off-by: Eric Van Hensbergen

Merge tag '9p-6.3-for-linus-part1' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs

2023-03-01T16:52:49+00:00

Pull 9p updates from Eric Van Hensbergen:

 - some fixes and cleanup setting up for a larger set of performance
   patches I've been working on

 - a contributed fixes relating to 9p/rdma

 - some contributed fixes relating to 9p/xen

* tag '9p-6.3-for-linus-part1' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs:
  fs/9p: fix error reporting in v9fs_dir_release
  net/9p: fix bug in client create for .L
  9p/rdma: unmap receive dma buffer in rdma_request()/post_recv()
  9p/xen: fix connection sequence
  9p/xen: fix version parsing
  fs/9p: Expand setup of writeback cache to all levels
  net/9p: Adjust maximum MSIZE to account for p9 header

net/9p: fix bug in client create for .L

2023-02-24T13:42:40+00:00

We are supposed to set fid->mode to reflect the flags
that were used to open the file.  We were actually setting
it to the creation mode which is the default perms of the
file not the flags the file was opened with.

Signed-off-by: Eric Van Hensbergen 
Reviewed-by: Dominique Martinet

9p/rdma: unmap receive dma buffer in rdma_request()/post_recv()

2023-02-24T13:42:28+00:00

When down_interruptible() or ib_post_send() failed in rdma_request(),
receive dma buffer is not unmapped. Add unmap action to error path.
Also if ib_post_recv() failed in post_recv(), dma buffer is not unmapped.
Add unmap action to error path.

Link: https://lkml.kernel.org/r/20230104020424.611926-1-shaozhengchao@huawei.com
Fixes: fc79d4b104f0 ("9p: rdma: RDMA Transport Support for 9P")
Signed-off-by: Zhengchao Shao 
Reviewed-by: Leon Romanovsky 
Signed-off-by: Dominique Martinet 
Signed-off-by: Eric Van Hensbergen

9p/xen: fix connection sequence

2023-02-24T13:42:15+00:00

Today the connection sequence of the Xen 9pfs frontend doesn't match
the documented sequence. It can work reliably only for a PV 9pfs device
having been added at boot time already, as the frontend is not waiting
for the backend to have set its state to "XenbusStateInitWait" before
reading the backend properties from Xenstore.

Fix that by following the documented sequence [1] (the documentation
has a bug, so the reference is for the patch fixing that).

[1]: https://lore.kernel.org/xen-devel/20230130090937.31623-1-jgross@suse.com/T/#u

Link: https://lkml.kernel.org/r/20230130113036.7087-3-jgross@suse.com
Fixes: 868eb122739a ("xen/9pfs: introduce Xen 9pfs transport driver")
Signed-off-by: Juergen Gross 
Reviewed-by: Simon Horman 
Signed-off-by: Dominique Martinet 
Signed-off-by: Eric Van Hensbergen

9p/xen: fix version parsing

2023-02-24T13:41:53+00:00

When connecting the Xen 9pfs frontend to the backend, the "versions"
Xenstore entry written by the backend is parsed in a wrong way.

The "versions" entry is defined to contain the versions supported by
the backend separated by commas (e.g. "1,2"). Today only version "1"
is defined. Unfortunately the frontend doesn't look for "1" being
listed in the entry, but it is expecting the entry to have the value
"1".

This will result in failure as soon as the backend will support e.g.
versions "1" and "2".

Fix that by scanning the entry correctly.

Link: https://lkml.kernel.org/r/20230130113036.7087-2-jgross@suse.com
Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend")
Signed-off-by: Juergen Gross 
Reviewed-by: Simon Horman 
Signed-off-by: Dominique Martinet 
Signed-off-by: Eric Van Hensbergen

net/9p: Adjust maximum MSIZE to account for p9 header

2023-02-23T22:39:36+00:00

Add maximum p9 header size to MSIZE to make sure we can
have page aligned data.

Signed-off-by: Eric Van Hensbergen 
Reviewed-by: Dominique Martinet

Merge tag 'for-linus-6.2-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

2023-01-12T23:02:20+00:00

Pull xen fixes from Juergen Gross:

 - two cleanup patches

 - a fix of a memory leak in the Xen pvfront driver

 - a fix of a locking issue in the Xen hypervisor console driver

* tag 'for-linus-6.2-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen/pvcalls: free active map buffer on pvcalls_front_free_map
  hvc/xen: lock console list traversal
  x86/xen: Remove the unused function p2m_index()
  xen: make remove callback of xen driver void returned

Merge tag '9p-for-6.2-rc1' of https://github.com/martinetd/linux

2022-12-23T19:39:18+00:00

Pull 9p updates from Dominique Martinet:

 - improve p9_check_errors to check buffer size instead of msize when
   possible (e.g. not zero-copy)

 - some more syzbot and KCSAN fixes

 - minor headers include cleanup

* tag '9p-for-6.2-rc1' of https://github.com/martinetd/linux:
  9p/client: fix data race on req->status
  net/9p: fix response size check in p9_check_errors()
  net/9p: distinguish zero-copy requests
  9p/xen: do not memcpy header into req->rc
  9p: set req refcount to zero to avoid uninitialized usage
  9p/net: Remove unneeded idr.h #include
  9p/fs: Remove unneeded idr.h #include

Treewide: Stop corrupting socket's task_frag

2022-12-20T01:28:49+00:00

Since moving to memalloc_nofs_save/restore, SUNRPC has stopped setting the
GFP_NOIO flag on sk_allocation which the networking system uses to decide
when it is safe to use current->task_frag.  The results of this are
unexpected corruption in task_frag when SUNRPC is involved in memory
reclaim.

The corruption can be seen in crashes, but the root cause is often
difficult to ascertain as a crashing machine's stack trace will have no
evidence of being near NFS or SUNRPC code.  I believe this problem to
be much more pervasive than reports to the community may indicate.

Fix this by having kernel users of sockets that may corrupt task_frag due
to reclaim set sk_use_task_frag = false.  Preemptively correcting this
situation for users that still set sk_allocation allows them to convert to
memalloc_nofs_save/restore without the same unexpected corruptions that are
sure to follow, unlikely to show up in testing, and difficult to bisect.

CC: Philipp Reisner 
CC: Lars Ellenberg 
CC: "Christoph Böhmwalder" 
CC: Jens Axboe 
CC: Josef Bacik 
CC: Keith Busch 
CC: Christoph Hellwig 
CC: Sagi Grimberg 
CC: Lee Duncan 
CC: Chris Leech 
CC: Mike Christie 
CC: "James E.J. Bottomley" 
CC: "Martin K. Petersen" 
CC: Valentina Manea 
CC: Shuah Khan 
CC: Greg Kroah-Hartman 
CC: David Howells 
CC: Marc Dionne 
CC: Steve French 
CC: Christine Caulfield 
CC: David Teigland 
CC: Mark Fasheh 
CC: Joel Becker 
CC: Joseph Qi 
CC: Eric Van Hensbergen 
CC: Latchesar Ionkov 
CC: Dominique Martinet 
CC: Ilya Dryomov 
CC: Xiubo Li 
CC: Chuck Lever 
CC: Jeff Layton 
CC: Trond Myklebust 
CC: Anna Schumaker 
CC: Steffen Klassert 
CC: Herbert Xu 

Suggested-by: Guillaume Nault 
Signed-off-by: Benjamin Coddington 
Reviewed-by: Guillaume Nault 
Signed-off-by: Jakub Kicinski