Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp995127pxj; Thu, 27 May 2021 17:18:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymyyZWm7j5Cfrdr83d5KW7HoOTCrKoaCxdlXm6naCre6Rthpo7Px9bvVnkp/2xunD/PxNJ X-Received: by 2002:a05:6402:124f:: with SMTP id l15mr4144763edw.94.1622161124518; Thu, 27 May 2021 17:18:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622161124; cv=none; d=google.com; s=arc-20160816; b=WKSVhK/SdFYSJm4OtDHpUYZuUxYocrPo5lny9+oz2PD2mYaa8XAmkWGwlXduwZfDFd dwwaDcSV5rxRgQ/Q3tAr/bioDpKRMS2STicnuPjBLwXrcvCDs5l0GfHRpqf4p7HJ7Csw awN+nOTn1QvP6reAV+ih069Dlo0UGRC57FbWXXvwEb3Yv78ionqPYFWsZj+PD3FrDhlw ZgerUkTQKl+SDTdM65EvtMKAIviTpDqbTuaS10QkhAn3Pz/4k4umPFfZ7CQYAC9Qrz0X K1ieW8pQHT/Aq03KmuuObr9Xtn8oO8KGCi35suCAKMnN/9xx+Ec/1Q9hEab/wN/Lpxwh H/JA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=QTDtw4CB7baAoCLRAIeO+jHV4FpiTudBqJ0pazqfceU=; b=xfX2Y6VSUGy3JgJYzJLsePnoSGeK1TlV92M0NYalgOKx+LOJQp05oikaQiq07Jw1oo fjwV11G0hRPi2Ltc8CP6NjM/m/yn7eV9cDMNUz8H3oquN1t/NKIzN1rkfwtYkFy3P+C6 lXTqw9UZEr8telBkQXn2rI2UIgMMqdlOpauu2edyTzgoPVpRlmTAuMJjw2qUBs7ZzZmq o6n1YZv1E0BmC6lXcwWaUS3d9S6v1j9QQFgsLxG1NxfJDuiicxf5UDdVIqX9WkbkmFqQ mlOBQpeaMTcUtzlQjx8SMVvwBq/kWEInGRBXEVrpOXyIxQx1IPe1H1o1/iU0KbmuygnI EFPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=USUAUQjU; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id kq11si3637372ejb.108.2021.05.27.17.18.15; Thu, 27 May 2021 17:18:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=USUAUQjU; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236421AbhE0XAC (ORCPT + 99 others); Thu, 27 May 2021 19:00:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:34186 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233203AbhE0XAC (ORCPT ); Thu, 27 May 2021 19:00:02 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B3324613B4; Thu, 27 May 2021 22:58:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622156308; bh=88+eV716DIdAR5tUqch1HNXLPldwfov0uEMbNQcqzSk=; h=From:To:Cc:Subject:Date:From; b=USUAUQjUtNWzqcudS3yex3pfLJhCHJxn96LN10teB1uRolUdbFXqmYtAIhr5fZwVA ydfAB/sAiwJZiJYP4mh+/NEhElElpFks/CCzimQypgzsvb2wM9zLCYRYhawT2aZHSw YKeByIJ7ToHN4hJsxZssdSBwe/YrTkR1XfbC9hb6wBnq001G2B4U3+rHLDHB2u+REG 4YTCve+HKoYqbBeVbT4kYn8kKkEJrnvsO1I/C+3rp6W7//306k4Vd8CYoUuGSd6dVx kALocVvXzUfJtzHWuZ+Zn0rOu3WcOxfmSWx0fOCnHfqkpROnbPbOUQDGugMtsZW5NU iPaRCYmERRmtw== From: Eric Biggers To: linux-fscrypt@vger.kernel.org Cc: linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Daniel Rosenberg , stable@vger.kernel.org Subject: [PATCH] fscrypt: fix derivation of SipHash keys on big endian CPUs Date: Thu, 27 May 2021 15:55:25 -0700 Message-Id: <20210527225525.2365513-1-ebiggers@kernel.org> X-Mailer: git-send-email 2.32.0.rc0.204.g9fa02ecfa5-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org From: Eric Biggers Typically, the cryptographic APIs that fscrypt uses take keys as byte arrays, which avoids endianness issues. However, siphash_key_t is an exception. It is defined as 'u64 key[2];', i.e. the 128-bit key is expected to be given directly as two 64-bit words in CPU endianness. fscrypt_derive_dirhash_key() forgot to take this into account. Therefore, the SipHash keys used to index encrypted+casefolded directories differ on big endian vs. little endian platforms. This makes such directories non-portable between these platforms. Fix this by always using the little endian order. This is a breaking change for big endian platforms, but this should be fine in practice since the encrypt+casefold support isn't known to actually be used on any big endian platforms yet. Fixes: aa408f835d02 ("fscrypt: derive dirhash key for casefolded directories") Cc: # v5.6+ Signed-off-by: Eric Biggers --- fs/crypto/keysetup.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index 261293fb7097..4d98377c07a7 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -221,6 +221,16 @@ int fscrypt_derive_dirhash_key(struct fscrypt_info *ci, sizeof(ci->ci_dirhash_key)); if (err) return err; + + /* + * The SipHash APIs expect the key as a pair of 64-bit words, not as a + * byte array. Make sure to use a consistent endianness. + */ + BUILD_BUG_ON(sizeof(ci->ci_dirhash_key) != 16); + BUILD_BUG_ON(ARRAY_SIZE(ci->ci_dirhash_key.key) != 2); + le64_to_cpus(&ci->ci_dirhash_key.key[0]); + le64_to_cpus(&ci->ci_dirhash_key.key[1]); + ci->ci_dirhash_key_initialized = true; return 0; } -- 2.32.0.rc0.204.g9fa02ecfa5-goog