From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6828ECD98D2 for ; Fri, 12 Jun 2026 19:01:12 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1wY774-00016g-Tp; Fri, 12 Jun 2026 15:00:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wY772-00015v-BI; Fri, 12 Jun 2026 15:00:16 -0400 Received: from kylie.crudebyte.com ([5.189.157.229]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wY770-0000HP-LQ; Fri, 12 Jun 2026 15:00:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crudebyte.com; s=kylie; h=Cc:To:Subject:Date:From:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Content-ID: Content-Description; bh=Sio1SWXYvc02xa8MgERLDYT1YFIJZK26XHMBNPIB4Fg=; b=ER8oI NFS04fV+EGH9fAxJKfEADuKcs2JJmw796vZlPjSEz0E1+wqhD6ktAcykk5pAtZAaYUpTqtXzV/M8Z ctLVr0zKIjQMOw08tDEnn6yV5A1XClpLfN9QdJDqbnTKVtlXTWLY+VrkxjehuYkgOrjrfp8FXlfvl fKboKwmgRhBJ8XaDBoMJpAX68Ob5rtdwDSZFEJ0Zv4lXMcnLfhfpG08gor4mzcFASGen/YB88ElzU i44cbtNfsmrXOCKDerBGszE27rjMyzr6gkRarYtSTfBwQG3NQwcP9ck1htT3RUxXBYuuYUaEqq9tp i5VCfciYKm2MAiaXkhujz784y2sOCq0iSEUslv6JafAS778yL+khoGyd3Y06z6JTpdOkGhUqtgVLR JpxVEPNtECp3O/esWf/4C2f3/UUKy4emMo4fqUb4UWIodPGxl/epZS2Yb2ah4psCa9+9vMwEUPHWY OSL0LQdLQU44queuAnjiaLZrTHRj2QNPMYns8PB2iLTkrInJ8TSXYUWgZaMDHAbadM89lGUEI18m+ jdPOPuvUz59dsPo2R/DEcowjWxYWFc+O0a72qh6lSa773mO5TzaiqVjk9CPTt+2+foh5pn6qgz8Jq oYcyCBH616+Hmn3nwjnXoeLlv88WsNid5ym0Q41EHawZPPHQez/sYUC/MQlepg=; Message-ID: From: Christian Schoenebeck Date: Fri, 12 Jun 2026 20:22:52 +0200 Subject: [PATCH v2 0/8] 9pfs: fix DoS via Treaddir (CVE-2026-9238) To: qemu-devel@nongnu.org, qemu-stable@nongnu.org Cc: Greg Kurz , Feifan Qian , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" Received-SPF: pass client-ip=5.189.157.229; envelope-from=f81a387a2de4f2172fd5830c5654f49d78102254@kylie.crudebyte.com; helo=kylie.crudebyte.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Feifan Qian reported a potential DoS and unbound host allocation via Treaddir request due to msize not being capped on Tversion handshake, and allocation size in Treaddir being capped too late. Attack Vector of Vulnerability: A malicious guest can negotiate a large 9P msize during Tversion handshake and then send Treaddir request with a large 'count' parameter. The 9p server would allocate host memory proportional to the negotiated 'msize' for collecting directory entries, before validating that the actual reply buffer can hold the response. If the reply buffer is smaller than what was allocated, the response marshalling fails, but the memory has already been consumed. This can lead to: - Unbound host memory allocation proportional to the negotiated msize. - Denial of service against the QEMU process. - Potential OOM conditions affecting entire host system. This series fixes this vulnerability on two layers. Summary of patches fixing this vulnerability: - Layer 1: Patches 1..4 cap msize during Tversion handshake to reasonable maximum value. It does so by limiting msize to the theoretical maximum msize value supported by transport implementation. - Layer 2: Patches 5..8 cap the allocated host memory in the Treaddir handler specifically to the current, real response buffer size of transport implementation. v2: - Patch 3: - Pick the smallest limit from all Xen rings. - Return zero if Xen's ring count is zero. - Patch 7: - Use a local iovec in_sg[2] array variable to avoid potential NULL pointer dereference. - Patch 8: - Fix potential underflow if response_buffer_size() returned a value smaller than 11. Christian Schoenebeck (8): hw/9pfs: add msize_limit transport callback 9pfs/virtio: implement msize_limit callback 9pfs/xen: implement msize_limit callback hw/9pfs: cap negotiated msize to transport limit hw/9pfs: add response_buffer_size transport callback 9pfs/virtio: implement response_buffer_size callback 9pfs/xen: implement response_buffer_size callback hw/9pfs: cap Treaddir allocation (CVE-2026-9238) hw/9pfs/9p.c | 34 ++++++++++++++++++++++++++++++++-- hw/9pfs/9p.h | 2 ++ hw/9pfs/virtio-9p-device.c | 17 +++++++++++++++++ hw/9pfs/xen-9p-backend.c | 31 +++++++++++++++++++++++++++++++ 4 files changed, 82 insertions(+), 2 deletions(-) -- 2.47.3