From patchwork Wed Oct 2 21:51:50 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jacob Keller X-Patchwork-Id: 13820475 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F3F18745F4 for ; Wed, 2 Oct 2024 21:52:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.14 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727905922; cv=none; b=PKpmMKGMmx3Kr/J5eVnCIMXFDkcukGZmdG7V7cMeI4v41ztb9SuEqurFLhaog6Ft7bJdYEigJhXuuGCRmVARkbIicjbwwLeY6UAUPMX7S30nn4q2O+csDzbnPu659o9hL1KrD1XwDKWipLeM4kwa6oPVTnSzILfqYV5hmvKyOL4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727905922; c=relaxed/simple; bh=o4z7omtLRT2zmn5et0qf82yqYCLxSBEY+ZsXa2BatcY=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=uINwtfbEMdjL8iJjy9wuVNL4uLoIBtXsZbs2C5+Xtewa2tDQ3EPPih0RRREEJFkc/7jNgo2XcKgqDWolhIbJ2grTW86tU94HZiqfyiXB5CCr5TJAZ0lKUkj7zkWMgT0d427kAG+AEJJbQcM8yq4Wky5YUox4qTaBUT0KT0MPty4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=azgNpxF4; arc=none smtp.client-ip=192.198.163.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="azgNpxF4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727905921; x=1759441921; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=o4z7omtLRT2zmn5et0qf82yqYCLxSBEY+ZsXa2BatcY=; b=azgNpxF4FifzQxZiIPNaODlVajCzxe/E5VtL/8zyGn4GRCPNVrmEDLYU B8W6oD/LY7y5YPTDExnQhBw2Evu+EB2FFZpvx660rA7Q17Jky1HevLyq4 8Q2Vj8V11+q56YdFPjdPyHWlzGC0YzE7m79405EMHN0wylT08vBBdPGBV BJ0fzjfzSWgM/+DtrHVD3Ahfo+0x3MWOcaQ9kmDiqw7f8rysleOGQNPXR E9WMn61s8RIuMsp/OqLyNtV7YvU+iOBh6XEjSeyBZ3u6fB9mkCLG1gCCR Wyvf3WzUJacT7AoT9KPrB6kKcNEDlIAx1vWN3tSxZYZ+e1eeYzhZR0h54 w==; X-CSE-ConnectionGUID: dgrQJJA7RQS4qssLkfnNog== X-CSE-MsgGUID: E3gg+j/vT8WiWwsUTuMRmA== X-IronPort-AV: E=McAfee;i="6700,10204,11213"; a="27262012" X-IronPort-AV: E=Sophos;i="6.11,172,1725346800"; d="scan'208";a="27262012" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Oct 2024 14:51:59 -0700 X-CSE-ConnectionGUID: Q0MGHWz6SuG9KdaxinPJqA== X-CSE-MsgGUID: 2wUiF/SsSC+0E2q07E3/UQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,172,1725346800"; d="scan'208";a="78673882" Received: from jekeller-desk.jf.intel.com ([10.166.241.20]) by fmviesa004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Oct 2024 14:51:59 -0700 From: Jacob Keller Date: Wed, 02 Oct 2024 14:51:50 -0700 Subject: [PATCH net-next v2 01/10] lib: packing: refuse operating on bit indices which exceed size of buffer Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20241002-packing-kunit-tests-and-split-pack-unpack-v2-1-8373e551eae3@intel.com> References: <20241002-packing-kunit-tests-and-split-pack-unpack-v2-0-8373e551eae3@intel.com> In-Reply-To: <20241002-packing-kunit-tests-and-split-pack-unpack-v2-0-8373e551eae3@intel.com> To: Andrew Morton , Vladimir Oltean , "David S. Miller" Cc: netdev@vger.kernel.org, Jacob Keller , Vladimir Oltean , Przemek Kitszel X-Mailer: b4 0.14.1 X-Patchwork-Delegate: kuba@kernel.org From: Vladimir Oltean While reworking the implementation, it became apparent that this check does not exist. There is no functional issue yet, because at call sites, "startbit" and "endbit" are always hardcoded to correct values, and never come from the user. Even with the upcoming support of arbitrary buffer lengths, the "startbit >= 8 * pbuflen" check will remain correct. This is because we intend to always interpret the packed buffer in a way that avoids discontinuities in the available bit indices. Signed-off-by: Vladimir Oltean Tested-by: Jacob Keller Signed-off-by: Jacob Keller Reviewed-by: Przemek Kitszel Reviewed-by: Vladimir Oltean --- lib/packing.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lib/packing.c b/lib/packing.c index 3f656167c17e..439125286d2b 100644 --- a/lib/packing.c +++ b/lib/packing.c @@ -86,8 +86,10 @@ int packing(void *pbuf, u64 *uval, int startbit, int endbit, size_t pbuflen, */ int plogical_first_u8, plogical_last_u8, box; - /* startbit is expected to be larger than endbit */ - if (startbit < endbit) + /* startbit is expected to be larger than endbit, and both are + * expected to be within the logically addressable range of the buffer. + */ + if (unlikely(startbit < endbit || startbit >= 8 * pbuflen || endbit < 0)) /* Invalid function call */ return -EINVAL;