From nobody Sun Feb 8 11:21:27 2026 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 E5AC716132E for ; Mon, 19 Aug 2024 17:52:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724089976; cv=none; b=Sf7ShOMk2EgcAqaLmmtiseVase0sQ+Unmt+A4IRMyxqBB44m8Ycd4qmglpPwh5CW3tgeViHLFhf1lgAJaaCg8cAMQhVdwQFAM9GE1s06Jrz+LWhmKUs/NflgHDH1nv9NB/aDp/jbu7r2Vc0aI83XGdmn9zZPZalDSHnDa9FRTtk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724089976; c=relaxed/simple; bh=cVTzqwZxap3iVomL1QKHBohhVggQhfoi3NhyFSh4m+c=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=ljqTdrXAV2SggrJFDp+CM/5f1a6Yo0ktTnIVg5QXDV4HWIvZqRcYu/lAVwYj6UVVvxSdPDw35LN9Tm5C1j1xD/zKuw8k1j227DBAbz23qKZ8IPWm3NfWhSQ7eQsmVmJnctqkAhtmxuKlAYf066PwGq5NIQOZQoy7z1LAzNbeRO4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=z9tLN+ju; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="z9tLN+ju" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-427fc9834deso2845e9.0 for ; Mon, 19 Aug 2024 10:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1724089973; x=1724694773; darn=vger.kernel.org; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:from:to:cc:subject:date:message-id:reply-to; bh=8gMtRG0oO8Nirv/pH9tl2QYzZXra6QzE+ysSHUsbX5Q=; b=z9tLN+juahjwDC8+QcDPPxrD8DA3F2I0uL4dNK3yogCpjEtSjW8vYbijTND6mNo1ZA P07sCtLvonv5nRXnuu+QtlXoC3oh8aJDM5rUfdY8DuenRvYRUgGcYDcC9ZhfxjLQ6wyz 7pYq2XvwPTa4gDWz73Aw0ljOXNJdaaDWl02Mfl1YCjF5ei93yYnpvG/bGoHL2VmDjeIN EVrG/FkT1DsDHuorEVhjYzzLmQ0TrECtChoJacencfXbqn5MiJCJJb3x7yAQT2X/uHvF QsuuqTCVYF/TrEN0M+0sdjT9UyrMduo6Q7IHvFdh2nmvEZD3gKQN/fnk6Zup+G8kWYlk +Ifw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724089973; x=1724694773; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8gMtRG0oO8Nirv/pH9tl2QYzZXra6QzE+ysSHUsbX5Q=; b=lF2MtB2k54Es4P/Xaohup1gzbiXO8UXvBf4YDQPhMLWxmcpiaB13i+fbbIVl4V2FCe 2SkddFf79P5tTcvgMuByvh4LmFM0F0KEpAwqyiR3vtJrYD1IbuV6tWxHB4yE2PXe8jyI flJZVp3eldlX9t3IAkrDaT2ljxUtrn4C7OXOLBYlTF2zgz9u24eC1OQCov5WV/lCoMRc EdWV9sOFwEQGYLCvBx70s5oVNK2Rr59OLCTRih8Sw+0oAe6UBQAHKohWxCXnC9hHoMWr kcXcBEC/lnz09yGIGP9iTJj2wj8w432Gt4ojYkswTZyRs3wANZpPmOvKwRPSwbr5SelX sKLw== X-Forwarded-Encrypted: i=1; AJvYcCWnSdfkrqBAgFds1L/2xohWrnuwLYRw5YVs9ZziaMRRcOltIg2Mviy6e2UDGT6Ozi4kP6pU/JRpVE+HuxTsMlknUe8nGeVSDqHy4tk8 X-Gm-Message-State: AOJu0YxJhEw+Gbm9AUa9zumc4fDn2F4+KzGMHKx8ZILb2kkRmYdPtCnf 0wXMQtIUlfaGnv2BuZauL/KA++N2QcaVCNxxTVxkbSkGiboV1wW98T+XXQ4kBg== X-Google-Smtp-Source: AGHT+IEfrtYkRbMyHE+evxSmNhWANR4xJdsvBU1gG/nyq5RBdF2604zrBs8r7RvRtK65WLsJyMDnjA== X-Received: by 2002:a05:600c:1f09:b0:426:66fd:5fac with SMTP id 5b1f17b1804b1-42ab6028c33mr25945e9.2.1724089972573; Mon, 19 Aug 2024 10:52:52 -0700 (PDT) Received: from localhost ([2a00:79e0:9d:4:90ba:acf6:9644:9e81]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-371898b8e8asm11120073f8f.116.2024.08.19.10.52.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Aug 2024 10:52:51 -0700 (PDT) From: Jann Horn Date: Mon, 19 Aug 2024 19:52:30 +0200 Subject: [PATCH] fuse: use unsigned type for getxattr/listxattr size truncation Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20240819-fuse-oob-error-fix-v1-1-9af04eeb4833@google.com> X-B4-Tracking: v=1; b=H4sIAF2Gw2YC/x2MQQqAIBAAvxJ7bkHFzPpKdKjcai8aK0UQ/T3pO AMzD2QSpgx99YDQxZlTLKDrCpZ9ihshh8JglLHK6w7XMxOmNCOJJMGVb3TOBuWNbl1ooISHUNH /dBjf9wNZy9uVZAAAAA== To: Miklos Szeredi Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Jann Horn X-Mailer: b4 0.15-dev X-Developer-Signature: v=1; a=ed25519-sha256; t=1724089967; l=2556; i=jannh@google.com; s=20240730; h=from:subject:message-id; bh=cVTzqwZxap3iVomL1QKHBohhVggQhfoi3NhyFSh4m+c=; b=k7g0mM4redxq0rCjuhFOUqDAemNc6dhKrUvEJAP8MN/HN7KDyKQIkFk803VCqqn5scePWum8q BKDV7gy4DECDxFhAP8KXxfgrb1YsT8BpZzgNMpu0+pI2gzhvJhCdYHB X-Developer-Key: i=jannh@google.com; a=ed25519; pk=AljNtGOzXeF6khBXDJVVvwSEkVDGnnZZYqfWhP1V+C8= The existing code uses min_t(ssize_t, outarg.size, XATTR_LIST_MAX) when parsing the FUSE daemon's response to a zero-length getxattr/listxattr request. On 32-bit kernels, where ssize_t and outarg.size are the same size, this is wrong: The min_t() will pass through any size values that are negative when interpreted as signed. fuse_listxattr() will then return this userspace-supplied negative value, which callers will treat as an error value. This kind of bug pattern can lead to fairly bad security bugs because of how error codes are used in the Linux kernel. If a caller were to convert the numeric error into an error pointer, like so: struct foo *func(...) { int len =3D fuse_getxattr(..., NULL, 0); if (len < 0) return ERR_PTR(len); ... } then it would end up returning this userspace-supplied negative value cast to a pointer - but the caller of this function wouldn't recognize it as an error pointer (IS_ERR_VALUE() only detects values in the narrow range in which legitimate errno values are), and so it would just be treated as a kernel pointer. I think there is at least one theoretical codepath where this could happen, but that path would involve virtio-fs with submounts plus some weird SELinux configuration, so I think it's probably not a concern in practice. Cc: stable@vger.kernel.org Fixes: 63401ccdb2ca ("fuse: limit xattr returned size") Signed-off-by: Jann Horn --- fs/fuse/xattr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/fuse/xattr.c b/fs/fuse/xattr.c index 5b423fdbb13f..9f568d345c51 100644 --- a/fs/fuse/xattr.c +++ b/fs/fuse/xattr.c @@ -81,7 +81,7 @@ ssize_t fuse_getxattr(struct inode *inode, const char *na= me, void *value, } ret =3D fuse_simple_request(fm, &args); if (!ret && !size) - ret =3D min_t(ssize_t, outarg.size, XATTR_SIZE_MAX); + ret =3D min_t(size_t, outarg.size, XATTR_SIZE_MAX); if (ret =3D=3D -ENOSYS) { fm->fc->no_getxattr =3D 1; ret =3D -EOPNOTSUPP; @@ -143,7 +143,7 @@ ssize_t fuse_listxattr(struct dentry *entry, char *list= , size_t size) } ret =3D fuse_simple_request(fm, &args); if (!ret && !size) - ret =3D min_t(ssize_t, outarg.size, XATTR_LIST_MAX); + ret =3D min_t(size_t, outarg.size, XATTR_LIST_MAX); if (ret > 0 && size) ret =3D fuse_verify_xattr_list(list, ret); if (ret =3D=3D -ENOSYS) { --- base-commit: b0da640826ba3b6506b4996a6b23a429235e6923 change-id: 20240819-fuse-oob-error-fix-664d082176d5 --=20 Jann Horn