From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F37C2AE8D for ; Sat, 27 Jun 2026 21:10:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782594634; cv=none; b=itA3/4voHdMuLqjp502CjAa9AhWMG/pKp0iq0dX4oLVam44LbyxdpdJw3ot7melTrDCs4WPoQmnOYi/XnR2FBbSCOyy4456ynIKkH7iCQ18/S7Hod1A/BS+Wj+XIgej5VxJc/om/B0QxqtPiThOdwd+3dSYId0RxW0K1n53qazI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782594634; c=relaxed/simple; bh=md8u99Rsv71oNA58KA/ltOKBoRbEgGc1clDD+mcrcns=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dnH7SjJlKkkdKMCYMsi+qJPfrqCONVjtb736/b2uGlVz5lXEyqsa62cYL5WKZwHwFVAr6dtbAFbqzVJIieUxsgSLJwHuYmxTg54Sr5Yn//vYHoMIztlYfGX642ZN0RsIY2oXxWkLeu8z7mAHyjYwHcyNwuxx+HGqPUpVapEIjSI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BFvvsTzr; arc=none smtp.client-ip=209.85.222.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BFvvsTzr" Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-922ff615c14so281139585a.3 for ; Sat, 27 Jun 2026 14:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782594631; x=1783199431; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=BXVVHr1pzRpCgstdGFWJchynEB/rshfqTO7LghYGjjA=; b=BFvvsTzrfrWAcXjHdBNWTN3SKdiEoUvf1XqFR0Q8Dq85EX9b7ODYfa2IKEXJjm98Yh IgSYlaPKgk4b62yEovnI1dy7FvVTeIBFI19BPxY2NdF+bunJ/nUGoBMiJjtrXFyJ2Fib WDcTlPGI8quMaGkHd6U6Y1/l0Hp9xAEqDt9Q6EpW/gWkzROPcgUwyiEhI7HoJF4Mroaq wYlwHN1CZdbqOp/DMxQgPuWIl9UjNKsoAgFyPsofFVweY/uXTNmc8SbVtMGXmlIAKx7Z +MJ4PTiXGNU5HFPu7JVpNNml8a5a3PUXTNBVI1hJgh2n5UlOQK91AiKPuRNWWaLMbrvb V/Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782594631; x=1783199431; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=BXVVHr1pzRpCgstdGFWJchynEB/rshfqTO7LghYGjjA=; b=qqXQcDJXKUIDWI/OcsKbUObP3zJv9QXDXYe3zSAobtnz4FPnWZtAHXxrDff46fvHjt 6MktHR1mR/nwihppGv3V1BlBiNTw1ItQuFWSdd99Xmee4nsMiGZ5QDYClu6QwJlz6Z86 xVadp34wsBqbaHyMeaBzhC99ZZGW2eQt4KaSQQjyjm/JTBt3i9PrfvzPqI2hk9MelegV nertq4UY0K5OihKHT1wIWwZSv2yy2BTzTTkaVQByZVytkzyNKxXx5vMUAMLMYEYmxyUD ufxqtnlvUeH89DGXC8FYr2Og7hq5GoTodGmmMP3lB4J8ScVaIkO4rLi7YI7GXGRzIdi9 8AEw== X-Forwarded-Encrypted: i=1; AFNElJ/V3EQJPED4ymgZp5pMf20buinrdgFxb0gyCFERjxEpauAxSam6VG3whQqEmJw1oZX/6dBPuMa4Jp1xK/Y=@vger.kernel.org X-Gm-Message-State: AOJu0YzqqgLhNTCt3zN1OQ82X6YwGPEQH5q0Dw1sM5JcYe0nvNrlcAGi cdgMLV4bHs24zeGIHq2GTtKXWa4wuudS47DwXiuaLuRANffJ/1wejO5B X-Gm-Gg: AfdE7cl3rcHH8Qgst6TN6MnhVXjX3P3aV5vnQvqS2R+8QGNl4Bxn6G0jjqdCIQ9c6T5 lOJzQ8pTTU40Ktzuku/pD42OkCdwXNrOK8CTBXp/WlcOlWunGXHXRas0WXVJ78z/HmLc/YYPK5d leJc68sZCYW0HcODuHm92Se5236jp6bFa0GiqOns0gHCrJrTgODV5xjwyPrNjQ2dtWWnBRqXPPX nhwjrE+vw6h+rZkj/ImYS9yQcrzSoJdq3L41CNaNL6Oqbw+1i07HZLU51MLgQx43OjUeSrSK/0l ICMm2wJc0v2TrOV5GwMST0OAVRoX5KwX1rKqsaGOFgUDA9+Ywlj8frLq2J5Jj3IVUuMm8MUQCzy 1Mpbn/zVYOMxbaU97kI9GQL9EGZcXKIXV5DN25hHvMVaZd+LRiYGHIsmu84f/ZjYeSSz4Gq1Ix/ xW/3oCmbvjFWi5vy9N7sDy2fd7tY72D4KtnhZNiY/AGlmdo2oRobFiEhwGTiJWeGq/C9zi715+T XgQm2JKYu7X1hw4MTX1YQvXKODYzpbv X-Received: by 2002:a05:620a:4399:b0:92e:452e:bcf with SMTP id af79cd13be357-92e452e14aemr233326385a.12.1782594631512; Sat, 27 Jun 2026 14:10:31 -0700 (PDT) Received: from server0.tail6e7dd.ts.net (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id af79cd13be357-925fda62183sm1587373985a.13.2026.06.27.14.10.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Jun 2026 14:10:30 -0700 (PDT) From: Michael Bommarito To: Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck Cc: v9fs@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v4] 9p/trans_virtio: reject mount tags longer than NAME_MAX at probe Date: Sat, 27 Jun 2026 17:10:12 -0400 Message-ID: <20260627211012.4042372-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260626111906.801890-1-michael.bommarito@gmail.com> References: <20260626111906.801890-1-michael.bommarito@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito --- v4: bound tag_len by NAME_MAX (255) instead of PAGE_SIZE, per Christian Schoenebeck's review of v3 -- a 9p mount tag is a name-like identifier, and NAME_MAX avoids hard-coding the seq_file page-size implementation detail (which could change and silently break the bound) and resolves the off-by-one he noted. v3: reject at probe time (PAGE_SIZE) instead of truncating in show(). v2: sysfs_emit() in show() -- dropped; probe-time rejection preferred. v1: bound the show() copy. Build-tested ARCH=um (net/9p/trans_virtio.o, W=1, clean; NAME_MAX resolves with no new include). The original ~64 KiB OOB write was reproduced pre-fix; with the probe bound a tag_len > 255 device is refused, so the show handler never sees an out-of-page tag. net/9p/trans_virtio.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c index b0d0094ec8e2c..9fa63e3ebf673 100644 --- a/net/9p/trans_virtio.c +++ b/net/9p/trans_virtio.c @@ -633,6 +633,11 @@ static int p9_virtio_probe(struct virtio_device *vdev) err = -EINVAL; goto out_free_vq; } + if (tag_len > NAME_MAX) { + dev_err(&vdev->dev, "mount tag too long (%u bytes)\n", tag_len); + err = -EINVAL; + goto out_free_vq; + } tag = kzalloc(tag_len + 1, GFP_KERNEL); if (!tag) { err = -ENOMEM; base-commit: 4edcdefd4083ae04b1a5656f4be6cd83ae919ef4 -- 2.53.0