summaryrefslogtreecommitdiff
path: root/net/9p
AgeCommit message (Collapse)Author
7 days9p: reject RERROR/RLERROR with zero errcodeHui Peng
In p9_check_errors() (net/9p/client.c), a malicious or buggy 9p server returning P9_RERROR or P9_RLERROR with ecode == 0 causes p9_check_errors() to return 0 (success) while leaving the unparsed response payload as if the expected reply message type succeeded. Map ecode == 0 on RERROR / RLERROR to -EPROTO. Link: https://lore.kernel.org/all/20260919221734.3708000-1-benquike@gmail.com/ Signed-off-by: Hui Peng <benquike@gmail.com> Message-ID: <20261029055801.3-1-asmadeus@codewreck.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
7 days9p/xen: validate the response size from the backendYehyeong Lee
p9_xen_response() takes the length of an incoming response from the ring -- the first field of the 9p header, which the Xen transport reuses as its framing header -- and uses it to advance the consumer index, but never checks that it is at least the header size or no larger than the number of bytes the backend has actually produced. A malicious or buggy backend can post a response whose size is smaller than the header (for example 0). The consumer index then never advances, so the response work re-reads the same ring contents instead of making progress. In testing this raced with the teardown that the malformed reply triggers and dereferenced a freed p9_client: 9pfs 9pfs-0: Wrong req tag=ffff BUG: kernel NULL pointer dereference, address: 0000000000000060 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 7.2.0-rc5 #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 Workqueue: events p9_xen_response RIP: 0010:idr_find+0x4/0x10 RSP: 0018:ffffbf5d80063de8 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa229c21195a0 RCX: ffffa229c2400000 RDX: ffffa229c11c2200 RSI: 000000000000ffff RDI: 0000000000000050 RBP: 000000000000ffff R08: 3fffffffffffdfff R09: ffffffffffffffff R10: 3fffffffffffdfff R11: ffffffff87a60e80 R12: 0000000000000050 R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000100000 FS: 0000000000000000(0000) GS:ffffa22a7661c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000060 CR3: 000000003ac34002 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> p9_tag_lookup+0x2b/0x90 p9_xen_response+0x17c/0x2e0 process_one_work+0x16a/0x3a0 worker_thread+0x172/0x2e0 kthread+0xdd/0x110 ret_from_fork+0x18b/0x240 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: CR2: 0000000000000060 ---[ end trace 0000000000000000 ]--- Reject a response whose size is outside [sizeof(header), queued] before using it, matching the validation the backend already applies to incoming requests. Fixes: f66c72bea129 ("xen/9pfs: receive responses") Cc: stable@vger.kernel.org Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr> Reviewed-by: Juergen Gross <jgross@suse.com> Message-ID: <20261005125640.274054-1-yhlee@isslab.korea.ac.kr> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-22net/9p/usbg: clear stale client pointer on closeHyungjung Joo
p9_usbg_close() tears down the client transport, but usb9pfs keeps using usb9pfs->client from asynchronous TX and RX completion handlers. A late completion can therefore dereference a client that has already been freed during mount teardown. Clear usb9pfs->client under usb9pfs->lock when closing the transport, detach any pending TX request from in_req->context, and make the TX/RX completion handlers bail out once the transport has been detached. This keeps late completions from touching a freed or rebound p9_client. Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Cc: stable@vger.kernel.org Signed-off-by: Hyungjung Joo <jhj140711@gmail.com> Signed-off-by: Michael Grzeschik <mgr@kernel.org> Message-ID: <20260922-usb9pfsfixes-v1-7-9d8dcc52904c@kernel.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-22net/9p/usbg: remove bogus context initialization in alloc_requestsMichael Grzeschik
alloc_requests() initializes usb9pfs->in_req->context to point at the struct f_usb9pfs instance itself. usb9pfs_queue_tx() later overwrites this with the real struct p9_req_t pointer before every transmit, and usb9pfs_tx_complete() clears it back to NULL after each completion, so in_req->context only ever holds a valid p9_req_t once a request has actually been queued. usb9pfs_clear_tx(), however, can run at any time (mount close, gadget disable) independent of whether a request was ever queued. If it runs before the first usb9pfs_transmit(), it reads the leftover sentinel value, type-confuses the struct f_usb9pfs pointer as a struct p9_req_t, and both writes through it (req->t_err = -ECONNRESET) and hands it to p9_client_cb(), which manipulates req->wq and req->refcount at bogus offsets inside f_usb9pfs. This reliably corrupts memory or panics whenever the transport is torn down before any 9p request has been transmitted, e.g. mounting and immediately unmounting, or a cable disconnect racing the very first request. usb9pfs->out_req->context is set the same way but is never read by this transport (usb9pfs_rx_complete() identifies the instance via ep->driver_data instead), so it serves no purpose either. Both endpoints' ->driver_data are already set to usb9pfs in enable_endpoint(), which is what the completion handlers actually use to recover the f_usb9pfs instance. Just drop the leftover ->context assignments; usb_ep_alloc_request()/alloc_ep_req() already return zeroed requests, so in_req->context correctly starts out NULL. Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Michael Grzeschik <mgr@kernel.org> Message-ID: <20260922-usb9pfsfixes-v1-6-9d8dcc52904c@kernel.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-22net/9p/usbg: fix out_req buffer leak in disable_usb9pfsMichael Grzeschik
usb9pfs->out_req is allocated with alloc_ep_req(), which also allocates the request's data buffer (req->buf). disable_usb9pfs() frees it with plain usb_ep_free_request(), which only frees the usb_request structure itself and leaks req->buf on every close. Use free_ep_req() instead, matching the allocator, as documented by its own comment ("Requests allocated via alloc_ep_req() *must* be freed by free_ep_req()"). Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Michael Grzeschik <mgr@kernel.org> Message-ID: <20260922-usb9pfsfixes-v1-5-9d8dcc52904c@kernel.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-22net/9p/usbg: call disable_usb9pfs() from usb9pfs_disable()Michael Grzeschik
usb9pfs_disable() is the usb_function ->disable callback, invoked by the composite gadget core whenever the host resets or unconfigures the gadget. The gadget function API requires this callback to disable its endpoints; every other in-tree function driver does so from its ->disable hook. usb9pfs_disable() never called disable_usb9pfs(), so the IN/OUT endpoints and their usb_request objects were left active and allocated across a host-driven disable. When the host later reconfigures the device, enable_usb9pfs() calls alloc_requests() again and unconditionally overwrites usb9pfs->in_req/out_req, permanently leaking the previous allocations, while the endpoints themselves are left enabled underneath the function's own idea of being disabled. Call disable_usb9pfs() before reinit_completion(&usb9pfs->send), mirroring the same sequence already used in p9_usbg_close(). Placing it before the reinit_completion() also ensures usb_ep_disable() has synchronously flushed any requests still queued in hardware before the completion is reset, closing the same race that motivated resetting the completion here in the first place. Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Assisted-by: Claude:claude-opus-4.8 Cc: stable@vger.kernel.org Signed-off-by: Michael Grzeschik <mgr@kernel.org> Message-ID: <20260922-usb9pfsfixes-v1-4-9d8dcc52904c@kernel.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-22net/9p/usbg: always reset completion when disconnectingMichael Grzeschik
When some tx or rx transfers were pending while closing the connection, the completion handler could catch one pending completion call. To ensure a normal start when mounting again, we have to reset the completion and flush any pending completions. Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Cc: stable@vger.kernel.org Signed-off-by: Michael Grzeschik <mgr@kernel.org> Message-ID: <20260922-usb9pfsfixes-v1-3-9d8dcc52904c@kernel.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-22net/9p/usbg: set client to Disconnected on usb9pfs_disableMichael Grzeschik
This patch is setting the client status to Disconnected, when the client is still in use. Otherwise a disconnected usb cable would run any use of the mount to faults. Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Cc: stable@vger.kernel.org Signed-off-by: Michael Grzeschik <mgr@kernel.org> Message-ID: <20260922-usb9pfsfixes-v1-2-9d8dcc52904c@kernel.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-22net/9p/usbg: also disable endpoints on p9_usbg_closeMichael Grzeschik
The close function has to fully reverse the state change of 9p_create (mount) and the potential call of set_alt(1). This includes to ensure that the usage of the endpoints is not active any more. Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Cc: stable@vger.kernel.org Signed-off-by: Michael Grzeschik <mgr@kernel.org> Message-ID: <20260922-usb9pfsfixes-v1-1-9d8dcc52904c@kernel.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-22net/9p/usbg: Fix use-after-free in disable_usb9pfs()Yizhou Zhao
disable_usb9pfs() frees the IN and OUT usb_request objects before it disables the corresponding endpoints. If either request is still queued, the later usb_ep_disable() call cancels the endpoint queue and the UDC driver can still access the already freed request. With dummy_hcd and KASAN, this is reproducible by queueing the OUT request and then disconnecting the configfs gadget: BUG: KASAN: slab-use-after-free in dummy_disable+0x2b4/0x300 Read of size 8 at addr ffff888009702400 by task sh/1 usb_ep_disable+0x8e/0x1f0 usb9pfs_func_unbind+0x193/0x350 gadget_dev_desc_UDC_store+0x135/0x280 dummy_free_request() also warns because the request is freed while its queue entry is still linked. Disable both endpoints before freeing the request objects. This lets usb_ep_disable() cancel any queued transfers and invoke the completion callback while the request storage is still valid. The request objects are then freed only after they have been removed from the endpoint queues. Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao@seu.edu.cn> Reported-by: Xuewei Feng <fengxw06@126.com> Reported-by: Qi Li <qli01@tsinghua.edu.cn> Reported-by: Ke Xu <xuke@tsinghua.edu.cn> Assisted-by: GLM:GLM-5.1 Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Acked-by: Michael Grzeschik <mgr@kernel.org> Message-ID: <20260607130118.16579-1-zhaoyz24@mails.tsinghua.edu.cn> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-229p: skip intermediate directory entry name copy in p9dirent_read()Haobin Wu
v9fs_dir_readdir_dotl() decodes each entry of a Rreaddir reply with p9dirent_read(), which parses it through p9pdu_readf("Qqbs"). The 's' conversion in p9pdu_vreadf() already allocates a NUL-terminated copy of the name from the wire buffer; p9dirent_read() then strscpy()s that copy into the fixed 256-byte p9_dirent::d_name and frees the original. The wire format carries the name length in 16 bits, so a name longer than 255 bytes is valid on the wire and may well be valid on the server's filesystem, but it makes strscpy() return -E2BIG. v9fs_dir_readdir_dotl() turns that into -EIO and aborts getdents64(), so every entry after the long one disappears from the listing. Drop the second copy: keep the string allocated by p9pdu_vreadf() in p9_dirent and let v9fs_dir_readdir_dotl(), its only user, free it once dir_emit() has consumed it. p9_dirent is a short-lived stack object, so the string's lifetime does not change. Note that the VFS only rejects names of PATH_MAX bytes or more in verify_dirent_name(), so after this change a name between NAME_MAX and PATH_MAX is returned by getdents64() even though any later lookup on it fails with -ENAMETOOLONG. The next patch skips such entries. Fixes: 7751bdb3a095 ("9p: readdir implementation for 9p2000.L") Closes: https://github.com/microsoft/WSL/issues/41192 Signed-off-by: Haobin Wu <853555@gmail.com> Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com> Message-ID: <20260918024851.51229-2-853555@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-229p/xen: drain response work after unbinding IRQYizhou Zhao
commit ea4f1009408e ("9p/xen : Fix use after free bug in xen_9pfs_front_remove due to race condition") added cancel_work_sync() to keep xen_9pfs_front_free() from freeing a ring while p9_xen_response() is still running. The work is currently drained before the event channel IRQ is unbound. That leaves a race window where xen_9pfs_front_event_handler() can run after cancel_work_sync() returns and queue p9_xen_response() again. The following unbind_from_irqhandler() synchronizes with the IRQ handler, but it does not cancel work that the handler already queued. The teardown can then free the ring and private data while the response work remains pending, and the worker later dereferences ring->priv and priv->client. Unbind the event channel IRQ before draining the work. Once the IRQ is unbound, no new response work can be queued by the backend event channel, and cancel_work_sync() waits for any work that was queued before or during the unbind. It is then safe to release the ring resources. Fixes: ea4f1009408e ("9p/xen : Fix use after free bug in xen_9pfs_front_remove due to race condition") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao@seu.edu.cn> Reported-by: Xuewei Feng <fengxw06@126.com> Reported-by: Qi Li <qli01@tsinghua.edu.cn> Reported-by: Ke Xu <xuke@tsinghua.edu.cn> Assisted-by: GLM:GLM-5.1 Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Message-ID: <20260609155202.1706-1-zhaoyz24@mails.tsinghua.edu.cn> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-229p/xen: Use array for data ringsRosen Penev
Store the fixed set of Xen 9p data rings in the frontend private allocation instead of allocating a separate rings array. This keeps the data ring storage tied to the frontend lifetime and simplifies the allocation and cleanup paths. Assisted-by: Codex:GPT-5.5 Signed-off-by: Rosen Penev <rosenp@gmail.com> Message-ID: <20260913192740.29668-1-rosenp@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-22net/9p: add vsock transportMatus Skvarla
Add vsock as a transport option for 9P client connections. This allows mounting 9P filesystems over VM sockets without requiring TCP/IP networking or additional userspace tools, which can be useful with hypervisors other than Qemu/KVM, for example Hyper-V/WSL which is used by podman machine on Windows[1][2]. The implementation extends trans_fd.c with vsock support, reusing the existing socket infrastructure. A new p9_fd_create_vsock() function handles vsock connection setup by parsing the CID from the mount source, creating an AF_VSOCK socket, and connecting to the specified endpoint. All other transport operations (close, request, cancel) use the shared fd transport implementation. The privport mount option is not currently implemented for vsock and returns -EOPNOTSUPP if specified. Add CONFIG_NET_9P_VSOCK option that conditionally compiles vsock support into 9pnet_fd.ko. This follows the pattern where socket-based transports (TCP, Unix, vsock) share trans_fd.c, while specialized hardware transports (virtio, xen, rdma) have dedicated files. Usage: mount -t 9p -o trans=vsock[,port=<port>] <CID> /mnt/point Link: https://github.com/podman-container-tools/podman/blob/main/cmd/podman/machine/server9p.go [1] Link: https://github.com/podman-container-tools/podman/blob/main/cmd/podman/machine/client9p.go [2] Signed-off-by: Matus Skvarla <skvarlamatus@gmail.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Stefano Garzarella <sgarzare@redhat.com> Message-ID: <20260709161741.15138-1-skvarlamatus@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-229p/xen: fix refcount leak in p9_xen_response() on wrong tagYifei Gao
p9_xen_response() looks up the request for an incoming reply with p9_tag_lookup(), which takes a reference on the returned p9_req_t. When the tag does not resolve to a request in REQ_STATUS_SENT, the function warns and continues the loop without dropping that reference, permanently leaking the p9_req_t and its msize buffers. The reply header, including the tag, is supplied by the backend, so a malicious or buggy 9P backend can leak kernel memory on every crafted response. Drop the reference before continuing. Fixes: 728356dedeff ("9p: Add refcount to p9_req_t") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yifei Gao <gyf161023@gmail.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Message-ID: <20260806144255.4167019-1-gyf161023@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-229p/trans_virtio: reject mount tags longer than NAME_MAX at probeMichael Bommarito
p9_virtio_probe() reads a 16-bit mount tag length (tag_len) from the device config and kzalloc()s tag_len + 1 bytes for chan->tag with no upper bound. A malicious or compromised host can present a tag of up to 65535 bytes; that tag is later copied into the single-page sysfs buffer by p9_mount_tag_show() (memcpy(buf, chan->tag, tag_len + 1)), a host-controlled out-of-bounds write of up to ~64 KiB past the PAGE_SIZE attribute buffer. Reject an overlong tag at probe time. A 9p mount tag is a name-like identifier, so bound it by NAME_MAX (255): that limit is independent of the sysfs/seq_file page size and is far above any legitimate mount tag, which keeps p9_mount_tag_show() safe at the root without hard-coding a seq_file implementation detail. Fixes: 179a5bc4b8cb ("net/9p: use memcpy() instead of snprintf() in p9_mount_tag_show()") Cc: stable@vger.kernel.org Suggested-by: Christian Schoenebeck <linux_oss@crudebyte.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com> Message-ID: <20260627211012.4042372-1-michael.bommarito@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-22net/9p/usbg: clear stale request context after abortChengfeng Ye
usb9pfs_clear_tx() serializes access to the active TX request with usb9pfs->lock, but leaves in_req->context pointing at the request after p9_client_cb() drops the transport reference. A later teardown path can therefore retrieve the same request after it has been freed: CPU 0 (p9_usbg_close) CPU 1 (usb9pfs_disable) lock(usb9pfs->lock) req = in_req->context p9_client_cb(client, req) p9_req_put(client, req) unlock(usb9pfs->lock) request reaches zero refs kmem_cache_free(req) lock(usb9pfs->lock) req = in_req->context read req->t_err The lock orders the two callbacks, but cannot protect a pointer that remains published after its reference has been released. KASAN reported: BUG: KASAN: slab-use-after-free in usb9pfs_clear_tx+0x166/0x1b0 Read of size 4 at addr ffff88810e7420f4 by task poc/94 Call Trace: usb9pfs_clear_tx+0x166/0x1b0 usb9pfs_disable+0x1d/0x30 reset_config+0x9d/0x200 __composite_disconnect+0xa7/0x140 Allocated by task 93: kmem_cache_alloc_noprof+0x141/0x370 p9_tag_alloc+0x8f/0x5b0 p9_client_prepare_req+0xff/0x350 p9_client_rpc+0x1a5/0xac0 Freed by task 0: slab_free_after_rcu_debug+0xa6/0x1e0 rcu_core+0x50a/0x1850 Last potentially related work creation: kmem_cache_free+0x1db/0x3d0 p9_req_put+0x164/0x1f0 usb9pfs_clear_tx+0x120/0x1b0 p9_usbg_close+0x7e/0x150 Clear in_req->context after the callback while still holding the lock. This matches the consume-and-clear pattern in usb9pfs_tx_complete(), so subsequent teardown calls return without touching the released request. The existing callback and error ordering remain unchanged. Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com> Signed-off-by: Qi Zhang <marsy12010123@gmail.com> Message-ID: <20260802152148.810390-1-marsy12010123@gmail.com> Acked-by: Michael Grzeschik <mgr@kernel.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-22net/9p/usbg: Fix use-after-free on usb9pfs_clear_txYizhou Zhao
When p9_usbg_close() is called, it invokes usb9pfs_clear_tx() but does not clear usb9pfs->client nor usb9pfs->in_req->context afterwards. The 9p client core (p9_client_destroy) calls close() and then kfree(clnt), so after p9_usbg_close returns the client struct is freed. If the USB gadget is later disabled (e.g., host disconnect), usb9pfs_disable calls usb9pfs_clear_tx again, which passes the dangling usb9pfs->client pointer to p9_client_cb. Inside p9_client_cb, p9_req_put(c, req) dereferences the freed client to access its reqs IDR, causing a use-after-free. Additionally, usb9pfs_clear_tx does not clear usb9pfs->in_req->context after calling p9_client_cb, so a second invocation finds a stale request pointer and attempts double-completion, further compounding the UAF risk. Fix by: 1. Clearing usb9pfs->in_req->context to NULL in usb9pfs_clear_tx() before checking usb9pfs->client, so that even if the client is gone the stale request pointer is consumed and cannot cause double-completion. 2. Adding a NULL check on usb9pfs->client in usb9pfs_clear_tx() to skip p9_client_cb() when the client has already been destroyed. 3. Setting usb9pfs->client = NULL in p9_usbg_close() after calling usb9pfs_clear_tx(), to prevent any subsequent call from dereferencing the freed client pointer. Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao@seu.edu.cn> Reported-by: Xuewei Feng <fengxw06@126.com> Reported-by: Qi Li <qli01@tsinghua.edu.cn> Reported-by: Ke Xu <xuke@tsinghua.edu.cn> Assisted-by: GLM:GLM-5.1 Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Message-ID: <20260529081026.77732-1-zhaoyz24@mails.tsinghua.edu.cn> Acked-by: Michael Grzeschik <mgr@kernel.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-13net/9p/usbg: fix prefix matching in device lookupYizhou Zhao
p9_usbg_create() matches the mount source against registered usb9pfs instance tags with strncmp() and the length of the caller supplied source. That accepts any prefix of the registered tag. For example, a gadget instance tagged "secret_channel" can be selected with "s", "sec", or any other non-empty prefix. Once selected, the instance is marked in use and the client is attached to that transport. This differs from the configfs tag lookup path, which uses strcmp() and therefore requires an exact tag match. Require an exact tag match in p9_usbg_create() as well. Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao@seu.edu.cn> Reported-by: Xuewei Feng <fengxw06@126.com> Reported-by: Qi Li <qli01@tsinghua.edu.cn> Reported-by: Ke Xu <xuke@tsinghua.edu.cn> Assisted-by: GLM:GLM-5.1 Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Co-developed-by: Jackie Liu <liuyun01@kylinos.cn> Signed-off-by: Jackie Liu <liuyun01@kylinos.cn> Message-ID: <20260607121907.12588-1-zhaoyz24@mails.tsinghua.edu.cn> Message-ID: <20260719040346.88295-1-liu.yun@linux.dev> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-13net/9p/usbg: fix descriptor cleanup use-after-freeYizhou Zhao
usb9pfs_free_func() frees the f_usb9pfs object before calling usb_free_all_descriptors(). The usb_function passed to the latter is embedded in the freed object, so removing the function from a gadget dereferences freed memory. The failing teardown sequence is: configfs unlink usb9pfs_free_func() kfree(usb9pfs) usb_free_all_descriptors(f) dereference the embedded usb_function KASAN reported: BUG: KASAN: slab-use-after-free in usb_free_all_descriptors+0x138/0x190 Read of size 8 at addr ffff888106a73088 by task poc/95 Call Trace: usb_free_all_descriptors+0x138/0x190 config_usb_cfg_unlink+0x1f0/0x2f0 configfs_unlink+0x321/0x6f0 Free the descriptors before freeing their containing object. Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao@seu.edu.cn> Reported-by: Xuewei Feng <fengxw06@126.com> Reported-by: Qi Li <qli01@tsinghua.edu.cn> Reported-by: Ke Xu <xuke@tsinghua.edu.cn> Assisted-by: GLM:GLM-5.1 Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Co-developed-by: Chengfeng Ye <nicoyip.dev@gmail.com> Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com> Acked-by: Michael Grzeschik <mgr@kernel.org> Message-ID: <20260529081817.77898-1-zhaoyz24@mails.tsinghua.edu.cn> Message-ID: <20260731150414.3135662-1-nicoyip.dev@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-09-139p: use fc->net_ns for network namespace in RDMA and socket transportsYizhou Zhao
The 9p RDMA transport currently passes &init_net to rdma_create_id(). As a result, RDMA address resolution and connection setup are performed in the initial network namespace, even when the mount is initiated from a non-initial network namespace. This differs from the socket-based 9p transports, which create sockets in current->nsproxy->net_ns. Use fc->net_ns for both the RDMA and socket transports instead, so that transport setup follows the VFS mount namespace context rather than depending on the calling process's current namespace. This avoids surprising behaviour where a 9p RDMA mount from a container or other non-initial network namespace may use the host namespace for RDMA CM operations. Fixes: fa20105e09e9 ("IB/cma: Add support for network namespaces") Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao@seu.edu.cn> Reported-by: Xuewei Feng <fengxw06@126.com> Reported-by: Qi Li <qli01@tsinghua.edu.cn> Reported-by: Ke Xu <xuke@tsinghua.edu.cn> Suggested-by: Dominique Martinet <asmadeus@codewreck.org> Assisted-by: GLM:GLM-5.1 Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Message-ID: <20260529090625.78761-1-zhaoyz24@mails.tsinghua.edu.cn> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-06-219p: Add missing read barrier in virtio zero-copy pathGui-Dong Han
Commit 2b6e72ed747f ("9P: Add memory barriers to protect request fields over cb/rpc threads handoff") added a read barrier after p9_client_rpc() waits for req->status, pairing with the write barrier in p9_client_cb(). The virtio zero-copy wait path was missed. Add the same read barrier after the zero-copy wait before reading the completed request. Fixes: 2b6e72ed747f ("9P: Add memory barriers to protect request fields over cb/rpc threads handoff") Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Message-ID: <20260529075441.233369-1-hanguidong02@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-06-21net/9p: Replace strlen() strcpy() pair with strscpy()David Laight
Use the result of strscpy() for the overflow check. Signed-off-by: David Laight <david.laight.linux@gmail.com> Message-ID: <20260606202744.5113-3-david.laight.linux@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-06-21net/9p: fix race condition on rdma->state in trans_rdma.cYizhou Zhao
The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions. Fixes: 473c7dd1d7b5 ("9p/rdma: remove useless check in cm_event_handler") Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao@seu.edu.cn> Reported-by: Xuewei Feng <fengxw06@126.com> Reported-by: Qi Li <qli01@tsinghua.edu.cn> Reported-by: Ke Xu <xuke@tsinghua.edu.cn> Assisted-by: GLM:GLM-5.1 Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Message-ID: <20260529073933.77315-1-zhaoyz24@mails.tsinghua.edu.cn> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-06-219p: avoid putting oldfid in p9_client_walk() error pathYizhou Zhao
When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request. Fixes: b48dbb998d70 ("9p fid refcount: add p9_fid_get/put wrappers") Cc: stable@vger.kernel.org Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao@seu.edu.cn> Reported-by: Xuewei Feng <fengxw06@126.com> Reported-by: Qi Li <qli01@tsinghua.edu.cn> Reported-by: Ke Xu <xuke@tsinghua.edu.cn> Assisted-by: GLM 5.1 Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Message-ID: <20260528053918.53550-1-zhaoyz24@mails.tsinghua.edu.cn> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-05-29net/9p: fix infinite loop in p9_client_rpc on fatal signalVasiliy Kovalev
When p9_client_rpc() is called with type P9_TFLUSH and the transport has no peer (e.g. fd transport backed by pipes with no 9p server), a fatal signal causes an infinite loop: again: err = io_wait_event_killable(req->wq, ...) /* SIGKILL wakes the task, returns -ERESTARTSYS */ if (err == -ERESTARTSYS && c->status == Connected && type == P9_TFLUSH) { sigpending = 1; clear_thread_flag(TIF_SIGPENDING); goto again; } clear_thread_flag() clears TIF_SIGPENDING before jumping back to io_wait_event_killable(). signal_pending_state() checks TIF_SIGPENDING, finds it zero, and the task goes to sleep again. The task can only wake on the next signal delivery that calls signal_wake_up() and sets TIF_SIGPENDING again. When that happens the loop repeats, clears TIF_SIGPENDING, and sleeps again indefinitely. This is triggered in practice by coredump_wait(): when a thread in a multi-threaded process causes a coredump (e.g. via SIGSYS from Syscall User Dispatch), coredump_wait() sends SIGKILL to all other threads and waits for them to call mm_release(). If one of those threads is blocked in p9_client_rpc() over an fd transport with no peer, it enters the P9_TFLUSH loop and never calls mm_release(), so coredump_wait() stalls forever: INFO: task syz.0.18:676 blocked for more than 143 seconds. Not tainted 6.12.77+ #1 task:syz.0.18 state:D stack:27600 pid:676 tgid:673 ppid:630 flags:0x00000004 Call Trace: <TASK> context_switch kernel/sched/core.c:5344 [inline] __schedule+0xcb4/0x5d50 kernel/sched/core.c:6724 __schedule_loop kernel/sched/core.c:6801 [inline] schedule+0xe5/0x350 kernel/sched/core.c:6816 schedule_timeout+0x253/0x290 kernel/time/timer.c:2593 do_wait_for_common kernel/sched/completion.c:95 [inline] __wait_for_common+0x409/0x600 kernel/sched/completion.c:116 wait_for_common kernel/sched/completion.c:127 [inline] wait_for_completion_state+0x1d/0x40 kernel/sched/completion.c:264 coredump_wait fs/coredump.c:448 [inline] do_coredump+0x854/0x4350 fs/coredump.c:629 get_signal+0x1425/0x2730 kernel/signal.c:2903 arch_do_signal_or_restart+0x81/0x880 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0xf9/0x160 kernel/entry/common.c:218 do_syscall_64+0x102/0x220 arch/x86/entry/common.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Fix: check fatal_signal_pending() before clearing TIF_SIGPENDING in the P9_TFLUSH retry loop. At that point TIF_SIGPENDING is still set, so fatal_signal_pending() works correctly. If a fatal signal is pending, jump to recalc_sigpending to restore TIF_SIGPENDING and return -ERESTARTSYS to the caller. The same defect is present in stable kernels back to 5.4. On those kernels the infinite loop is broken earlier by a second SIGKILL from the parent process (e.g. kill_and_wait() retrying after a timeout), resulting in a zombie process and a shutdown delay rather than a permanent D-state hang, but the underlying flaw is the same. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 91b8534fa8f5 ("9p: make rpc code common and rework flush code") Closes: https://syzkaller.appspot.com/bug?extid=3ce7863f8fc836a427e7 Cc: stable@vger.kernel.org Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org> Message-ID: <20260415155237.182891-1-kovalev@altlinux.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-05-199p: use kvzalloc for readdir bufferPierre Barre
The readdir buffer is sized to msize, so kzalloc() can fail under fragmentation with a page allocation failure in v9fs_alloc_rdir_buf() / v9fs_dir_readdir_dotl(). The buffer is only a response sink and is never pack_sg_list()'d, so kvzalloc() is safe for all transports, unlike the fcall buffers fixed in e21d451a82f3 ("9p: Use kvmalloc for message buffers on supported transports"). Signed-off-by: Pierre Barre <pierre@barre.sh> Message-ID: <20260512132032.369281-1-pierre@barre.sh> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-05-19net/9p/usbg: Constify struct configfs_item_operationsChristophe JAILLET
'struct configfs_item_operations' is not modified in this driver. Constifying this structure moves some data to a read-only section, so increases overall security, especially when the structure holds some function pointers. On a x86_64, with allmodconfig: Before: ====== text data bss dec hex filename 25167 9336 256 34759 87c7 net/9p/trans_usbg.o After: ===== text data bss dec hex filename 25231 9272 256 34759 87c7 net/9p/trans_usbg.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Message-ID: <2478bdabd7d169a686879c049f11dc307b5debbd.1778922467.git.christophe.jaillet@wanadoo.fr> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-04-169p/trans_xen: replace simple_strto* with kstrtouintYufan Chen
In xen_9pfs_front_init(), parse the backend version list as comma-separated tokens with kstrtouint(), keep strict token validation, and explicitly require protocol version 1 to be present. This replaces the deprecated simple_strtoul(), improves error reporting consistency, and avoids partially parsed values in control paths. Signed-off-by: Yufan Chen <ericterminal@gmail.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Message-ID: <20260324153023.86853-3-ericterminal@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-04-169p/trans_xen: make cleanup idempotent after dataring alloc errorsYufan Chen
xen_9pfs_front_alloc_dataring() tears down resources on failure but leaves ring fields stale. If xen_9pfs_front_init() later jumps to the common error path, xen_9pfs_front_free() may touch the same resources again, causing duplicate/invalid gnttab_end_foreign_access() calls and potentially dereferencing a freed intf pointer. Initialize dataring sentinels before allocation, gate teardown on those sentinels, and clear ref/intf/data/irq immediately after each release. This keeps cleanup idempotent for partially initialized rings and prevents repeated teardown during init failure handling. Signed-off-by: Yufan Chen <ericterminal@gmail.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Message-ID: <20260324153023.86853-2-ericterminal@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-02-21Convert 'alloc_obj' family to use the new default GFP_KERNEL argumentLinus Torvalds
This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21treewide: Replace kmalloc with kmalloc_obj for non-scalar typesKees Cook
This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org>
2026-01-299p/xen: protect xen_9pfs_front_free against concurrent callsStefano Stabellini
The xenwatch thread can race with other back-end change notifications and call xen_9pfs_front_free() twice, hitting the observed general protection fault due to a double-free. Guard the teardown path so only one caller can release the front-end state at a time, preventing the crash. This is a fix for the following double-free: [ 27.052347] Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 27.052357] CPU: 0 UID: 0 PID: 32 Comm: xenwatch Not tainted 6.18.0-02087-g51ab33fc0a8b-dirty #60 PREEMPT(none) [ 27.052363] RIP: e030:xen_9pfs_front_free+0x1d/0x150 [ 27.052368] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 41 55 41 54 55 48 89 fd 48 c7 c7 48 d0 92 85 53 e8 cb cb 05 00 48 8b 45 08 48 8b 55 00 <48> 3b 28 0f 85 f9 28 35 fe 48 3b 6a 08 0f 85 ef 28 35 fe 48 89 42 [ 27.052377] RSP: e02b:ffffc9004016fdd0 EFLAGS: 00010246 [ 27.052381] RAX: 6b6b6b6b6b6b6b6b RBX: ffff88800d66e400 RCX: 0000000000000000 [ 27.052385] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000000 RDI: 0000000000000000 [ 27.052389] RBP: ffff88800a887040 R08: 0000000000000000 R09: 0000000000000000 [ 27.052393] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888009e46b68 [ 27.052397] R13: 0000000000000200 R14: 0000000000000000 R15: ffff88800a887040 [ 27.052404] FS: 0000000000000000(0000) GS:ffff88808ca57000(0000) knlGS:0000000000000000 [ 27.052408] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 27.052412] CR2: 00007f9714004360 CR3: 0000000004834000 CR4: 0000000000050660 [ 27.052418] Call Trace: [ 27.052420] <TASK> [ 27.052422] xen_9pfs_front_changed+0x5d5/0x720 [ 27.052426] ? xenbus_otherend_changed+0x72/0x140 [ 27.052430] ? __pfx_xenwatch_thread+0x10/0x10 [ 27.052434] xenwatch_thread+0x94/0x1c0 [ 27.052438] ? __pfx_autoremove_wake_function+0x10/0x10 [ 27.052442] kthread+0xf8/0x240 [ 27.052445] ? __pfx_kthread+0x10/0x10 [ 27.052449] ? __pfx_kthread+0x10/0x10 [ 27.052452] ret_from_fork+0x16b/0x1a0 [ 27.052456] ? __pfx_kthread+0x10/0x10 [ 27.052459] ret_from_fork_asm+0x1a/0x30 [ 27.052463] </TASK> [ 27.052465] Modules linked in: [ 27.052471] ---[ end trace 0000000000000000 ]--- Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Message-ID: <20260129230348.2390470-1-stefano.stabellini@amd.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2026-01-299p: Track 9P RPC waiting time as IORemi Pommarel
Use io_wait_event_killable() to ensure that time spent waiting for 9P RPC transactions is accounted as IO wait time. Signed-off-by: Remi Pommarel <repk@triplefau.lt> Message-ID: <b8601271263011203fa34eada2e8ac21d9f679e5.1769179462.git.repk@triplefau.lt> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-12-07Merge tag '9p-for-6.19-rc1' of https://github.com/martinetd/linuxLinus Torvalds
Pull 9p updates from Dominique Martinet: - fix a bug with O_APPEND in cached mode causing data to be written multiple times on server - use kvmalloc for trans_fd to avoid problems with large msize and fragmented memory This should hopefully be used in more transports when time allows - convert to new mount API - minor cleanups * tag '9p-for-6.19-rc1' of https://github.com/martinetd/linux: 9p: fix new mount API cache option handling 9p: fix cache/debug options printing in v9fs_show_options 9p: convert to the new mount API 9p: create a v9fs_context structure to hold parsed options net/9p: move structures and macros to header files fs/fs_parse: add back fsparam_u32hex fs/9p: delete unnnecessary condition fs/9p: Don't open remote file with APPEND mode when writeback cache is used net/9p: cleanup: change p9_trans_module->def to bool 9p: Use kvmalloc for message buffers on supported transports
2025-11-04net: Convert proto_ops connect() callbacks to use sockaddr_unsizedKees Cook
Update all struct proto_ops connect() callback function prototypes from "struct sockaddr *" to "struct sockaddr_unsized *" to avoid lying to the compiler about object sizes. Calls into struct proto handlers gain casts that will be removed in the struct proto conversion patch. No binary changes expected. Signed-off-by: Kees Cook <kees@kernel.org> Link: https://patch.msgid.link/20251104002617.2752303-3-kees@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-04net: Convert proto_ops bind() callbacks to use sockaddr_unsizedKees Cook
Update all struct proto_ops bind() callback function prototypes from "struct sockaddr *" to "struct sockaddr_unsized *" to avoid lying to the compiler about object sizes. Calls into struct proto handlers gain casts that will be removed in the struct proto conversion patch. No binary changes expected. Signed-off-by: Kees Cook <kees@kernel.org> Link: https://patch.msgid.link/20251104002617.2752303-2-kees@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-039p: convert to the new mount APIEric Sandeen
Convert 9p to the new mount API. This patch consolidates all parsing into fs/9p/v9fs.c, which stores all results into a filesystem context which can be passed to the various transports as needed. Some of the parsing helper functions such as get_cache_mode() have been eliminated in favor of using the new mount API's enum param type, for simplicity. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Message-ID: <20251010214222.1347785-5-sandeen@redhat.com> [ Dominique: handled source explicitly as per follow-up discussion ] Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-11-03net/9p: move structures and macros to header filesEric Sandeen
With the new mount API all option parsing will need to happen in fs/v9fs.c, so move some existing data structures and macros to header files to facilitate this. Rename some to reflect the transport they are used for (rdma, fd, etc), for clarity. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Message-ID: <20251010214222.1347785-3-sandeen@redhat.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-11-03net/9p: cleanup: change p9_trans_module->def to boolDominique Martinet
'->def' is only ever used as a true/false flag Reported-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Message-ID: <20251103-v9fs_trans_def_bool-v1-1-f33dc7ed9e81@codewreck.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-11-039p: Use kvmalloc for message buffers on supported transportsPierre Barre
While developing a 9P server (https://github.com/Barre/ZeroFS) and testing it under high-load, I was running into allocation failures. The failures occur even with plenty of free memory available because kmalloc requires contiguous physical memory. This results in errors like: ls: page allocation failure: order:7, mode:0x40c40(GFP_NOFS|__GFP_COMP) This patch introduces a transport capability flag (supports_vmalloc) that indicates whether a transport can work with vmalloc'd buffers (non-physically contiguous memory). Transports requiring DMA should leave this flag as false. The fd-based transports (tcp, unix, fd) set this flag to true, and p9_fcall_init will use kvmalloc instead of kmalloc for these transports. This allows the allocator to fall back to vmalloc when contiguous physical memory is not available. Additionally, if kmem_cache_alloc fails, the code falls back to kvmalloc for transports that support it. Signed-off-by: Pierre Barre <pierre@barre.sh> Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com> Message-ID: <d2017c29-11fb-44a5-bd0f-4204329bbefb@app.fastmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-09-199p/trans_fd: p9_fd_request: kick rx thread if EPOLLINOleg Nesterov
p9_read_work() doesn't set Rworksched and doesn't do schedule_work(m->rq) if list_empty(&m->req_list). However, if the pipe is full, we need to read more data and this used to work prior to commit aaec5a95d59615 ("pipe_read: don't wake up the writer if the pipe is still full"). p9_read_work() does p9_fd_read() -> ... -> anon_pipe_read() which (before the commit above) triggered the unnecessary wakeup. This wakeup calls p9_pollwake() which kicks p9_poll_workfn() -> p9_poll_mux(), p9_poll_mux() will notice EPOLLIN and schedule_work(&m->rq). This no longer happens after the optimization above, change p9_fd_request() to use p9_poll_mux() instead of only checking for EPOLLOUT. Reported-by: syzbot+d1b5dace43896bc386c3@syzkaller.appspotmail.com Tested-by: syzbot+d1b5dace43896bc386c3@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68a2de8f.050a0220.e29e5.0097.GAE@google.com/ Link: https://lore.kernel.org/all/67dedd2f.050a0220.31a16b.003f.GAE@google.com/ Co-developed-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Oleg Nesterov <oleg@redhat.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Message-ID: <20250819161013.GB11345@redhat.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-08-23net/9p: fix double req put in p9_fd_cancelledNalivayko Sergey
Syzkaller reports a KASAN issue as below: general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f] CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:__list_del include/linux/list.h:114 [inline] RIP: 0010:__list_del_entry include/linux/list.h:137 [inline] RIP: 0010:list_del include/linux/list.h:148 [inline] RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734 Call Trace: <TASK> p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 This happens because of a race condition between: - The 9p client sending an invalid flush request and later cleaning it up; - The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ... Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystem client where the req_list could be deleted simultaneously by both p9_read_work and p9_fd_cancelled functions, but for the case where req->status equals REQ_STATUS_RCVD. Update the check for req->status in p9_fd_cancelled to skip processing not just received requests, but anything that is not SENT, as whatever changed the state from SENT also removed the request from its list. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: afd8d6541155 ("9P: Add cancelled() to the transport functions.") Cc: stable@vger.kernel.org Signed-off-by: Nalivayko Sergey <Sergey.Nalivayko@kaspersky.com> Message-ID: <20250715154815.3501030-1-Sergey.Nalivayko@kaspersky.com> [updated the check from status == RECV || status == ERROR to status != SENT] Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-08-23net/9p: Fix buffer overflow in USB transport layerDominique Martinet
A buffer overflow vulnerability exists in the USB 9pfs transport layer where inconsistent size validation between packet header parsing and actual data copying allows a malicious USB host to overflow heap buffers. The issue occurs because: - usb9pfs_rx_header() validates only the declared size in packet header - usb9pfs_rx_complete() uses req->actual (actual received bytes) for memcpy This allows an attacker to craft packets with small declared size (bypassing validation) but large actual payload (triggering overflow in memcpy). Add validation in usb9pfs_rx_complete() to ensure req->actual does not exceed the buffer capacity before copying data. Reported-by: Yuhao Jiang <danisjiang@gmail.com> Closes: https://lkml.kernel.org/r/20250616132539.63434-1-danisjiang@gmail.com Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Cc: stable@vger.kernel.org Message-ID: <20250622-9p-usb_overflow-v3-1-ab172691b946@codewreck.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-05-21netfs: Fix the request's work item to not require a refDavid Howells
When the netfs_io_request struct's work item is queued, it must be supplied with a ref to the work item struct to prevent it being deallocated whilst on the queue or whilst it is being processed. This is tricky to manage as we have to get a ref before we try and queue it and then we may find it's already queued and is thus already holding a ref - in which case we have to try and get rid of the ref again. The problem comes if we're in BH or IRQ context and need to drop the ref: if netfs_put_request() reduces the count to 0, we have to do the cleanup - but the cleanup may need to wait. Fix this by adding a new work item to the request, ->cleanup_work, and dispatching that when the refcount hits zero. That can then synchronously cancel any outstanding work on the main work item before doing the cleanup. Adding a new work item also deals with another problem upstream where it's sometimes changing the work func in the put function and requeuing it - which has occasionally in the past caused the cleanup to happen incorrectly. As a bonus, this allows us to get rid of the 'was_async' parameter from a bunch of functions. This indicated whether the put function might not be permitted to sleep. Fixes: 3d3c95046742 ("netfs: Provide readahead and readpage netfs helpers") Signed-off-by: David Howells <dhowells@redhat.com> Link: https://lore.kernel.org/20250519090707.2848510-4-dhowells@redhat.com cc: Paulo Alcantara <pc@manguebit.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Steve French <stfrench@microsoft.com> cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-03-239p: Use hashtable.h for hash_errmapSasha Levin
Convert hash_errmap in error.c to use the generic hashtable implementation from hashtable.h instead of the manual hlist_head array implementation. This simplifies the code and makes it more maintainable by using the standard hashtable API and removes the need for manual hash table management. Signed-off-by: Sasha Levin <sashal@kernel.org> Message-ID: <20250320145200.3124863-1-sashal@kernel.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-03-199p/trans_fd: mark concurrent read and writes to p9_conn->errIgnacio Encinas
Writes for the error value of a connection are spinlock-protected inside p9_conn_cancel, but lockless reads are present elsewhere to avoid performing unnecessary work after an error has been met. Mark the write and lockless reads to make KCSAN happy. Mark the write as exclusive following the recommendation in "Lock-Protected Writes with Lockless Reads" in tools/memory-model/Documentation/access-marking.txt while we are at it. Mark p9_fd_request and p9_conn_cancel m->err reads despite the fact that they do not race with concurrent writes for stylistic reasons. Reported-by: syzbot+d69a7cc8c683c2cb7506@syzkaller.appspotmail.com Reported-by: syzbot+483d6c9b9231ea7e1851@syzkaller.appspotmail.com Signed-off-by: Ignacio Encinas <ignacio@iencinas.com> Message-ID: <20250318-p9_conn_err_benign_data_race-v3-1-290bb18335cc@iencinas.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-03-199p/net: return error on bogus (longer than requested) repliesDominique Martinet
Up until now we've been considering longer than requested replies as acceptable, printing a message and just truncating the data, but it makes more sense to consider these an error. Make these fail with EIO instead. Suggested-by: Christian Schoenebeck <linux_oss@crudebyte.com> Message-ID: <20250317-p9_bogus_io_error-v1-1-9639f6d1561f@codewreck.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-03-199p/net: fix improper handling of bogus negative read/write repliesDominique Martinet
In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed. Make variables unsigned to avoid this problem. The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3) Reported-by: Robert Morris <rtm@mit.edu> Closes: https://lore.kernel.org/16271.1734448631@26-5-164.dynamic.csail.mit.edu Message-ID: <20250319-9p_unsigned_rw-v3-1-71327f1503d0@codewreck.org> Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-01-20net/9p/fd: support ipv6 for trans=tcpJoshua Murphy
Allows specifying an IPv6 address when mounting a remote 9p file system. Signed-off-by: Joshua Murphy <joshuamurphy@posteo.net> Message-ID: <20250118192122.327-2-joshuamurphy@posteo.net> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
generated by cgit v1.2.3 (git 2.0.4) at 2026-11-04 20:07:58 +0000