Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4075303pxb; Mon, 8 Feb 2021 07:22:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJxU14Y/ArcxJSfPGKVcohbgXIVuoHe90wAMXMcJ6OjSagNHqxQngWjSWZ2bOAdWdvy/OYIH X-Received: by 2002:aa7:c58f:: with SMTP id g15mr10392468edq.383.1612797722671; Mon, 08 Feb 2021 07:22:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612797722; cv=none; d=google.com; s=arc-20160816; b=huPUsm38NZbqv84j7BUX6D08cnuWSw0tKM0ZmQymLJ2d/yIR+JIaz73OPY5ywx/fZ3 joYBQxJ+PK9h3tclyiacpSPan3xPh4+qfCodj70Lo1yWifPEKhqkZTKrBYT5xabYfpi1 d1f4+rCCWD8RWGooV4Tan/5BPhcTw+nDsrDVu+ZllR5gOUdfXXo1V8PcoOF89CVpFk0J PFGtURHVkU51d19hSD2prXVerttS7a0JlRh27zY1GKKM3sekFOv8suhgLcXsuZzRWlQM pTrHNbjbX3A6d7d2itMIYNWJuSueE+zg4sv1rXQsqhiVOm5dtLVghTmURuOryT9hzwUC /VOQ== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=e4iGQKa7NTP9hLqDco9VMK1jbpG69h42YP414lfAapE=; b=WYK7pVN4BY8dM0QPXocED6roHT+HScj8lsGH+LqqOORxO+z4BV5/qfMRHHfFYT6hGW jR9eogqtN72oH0F/bhhq7sAyJSD9fRm/hxpiIvACnWqZ4cEaCtI517g1PrXixH4iVpG+ RaUzu6OgCy+t0E+ilnjYT/SAybdzguHAilnGduR2QV7x9SnFG3/sNDPJK2f2vf5I/n46 x9VeLbmp7XLL8lfLFZYoUhqzi4E7+PFLlYgyYpsyUhDXWZOUU4oGYbKwgVcA30trGWdj k1gKkby+d76euSPAI/xcfKOf0cVlMf/h49SVlycNotY2VUgsZc2EtPcn7fda9VXoDBEE hdyQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=kmvpBhnP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hs28si12112288ejc.141.2021.02.08.07.21.37; Mon, 08 Feb 2021 07:22:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-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=@linuxfoundation.org header.s=korg header.b=kmvpBhnP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233671AbhBHPTr (ORCPT + 99 others); Mon, 8 Feb 2021 10:19:47 -0500 Received: from mail.kernel.org ([198.145.29.99]:52060 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232876AbhBHPD5 (ORCPT ); Mon, 8 Feb 2021 10:03:57 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 58E7F64EB7; Mon, 8 Feb 2021 15:03:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1612796606; bh=5n1+5pAYKydUCiYwImBD9lr7EVtVsDVK+XpcP8nmQNU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kmvpBhnPW7osq9RSpeWmaGTnObtvBCAOAjz4Mm2tRei4w6gvevo8KXmX6EsZj75p/ ws1YATvSLdGKYEull7SYQBMRTyS8UdKgj9hvLwNb6o/FXBVVc12bVf2gZ8YeCCMdgD Da21R9Lz1uu6YO4mZIKRDzAlg632Jbcd/VLlNqZQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sasha Levin Subject: [PATCH 4.4 15/38] stable: clamp SUBLEVEL in 4.4 and 4.9 Date: Mon, 8 Feb 2021 16:00:37 +0100 Message-Id: <20210208145805.898658055@linuxfoundation.org> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20210208145805.279815326@linuxfoundation.org> References: <20210208145805.279815326@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Right now SUBLEVEL is overflowing, and some userspace may start treating 4.9.256 as 4.10. While out of tree modules have different ways of extracting the version number (and we're generally ok with breaking them), we do care about breaking userspace and it would appear that this overflow might do just that. Our rules around userspace ABI in the stable kernel are pretty simple: we don't break it. Thus, while userspace may be checking major/minor, it shouldn't be doing anything with sublevel. This patch applies a big band-aid to the 4.9 and 4.4 kernels in the form of clamping their sublevel to 255. The clamp is done for the purpose of LINUX_VERSION_CODE only, and extracting the version number from the Makefile or "make kernelversion" will continue to work as intended. We might need to do it later in newer trees, but maybe we'll have a better solution by then, so I'm ignoring that problem for now. Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/Makefile +++ b/Makefile @@ -1068,7 +1068,7 @@ endef define filechk_version.h (echo \#define LINUX_VERSION_CODE $(shell \ - expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \ + expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255); \ echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';) endef