Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 10 Apr 2023 08:43:31 -0400
From:   "Liam R. Howlett" <Liam.Howlett@Oracle.com>
To:     Peng Zhang <zhangpeng.00@bytedance.com>
Cc:     akpm@linux-foundation.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, maple-tree@lists.infradead.org,
        stable@vger.kernel.org
Subject: Re: [PATCH 2/2] maple_tree: Fix a potential memory leak, OOB access,
 or other unpredictable bug
Message-ID: <20230410124331.kijufkik2qlxoxjz@revolver>
Mail-Followup-To: "Liam R. Howlett" <Liam.Howlett@Oracle.com>,
        Peng Zhang <zhangpeng.00@bytedance.com>, akpm@linux-foundation.org,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        maple-tree@lists.infradead.org, stable@vger.kernel.org
References: <20230407040718.99064-1-zhangpeng.00@bytedance.com>
 <20230407040718.99064-2-zhangpeng.00@bytedance.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230407040718.99064-2-zhangpeng.00@bytedance.com>
User-Agent: NeoMutt/20220429
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?02zIzbTVroYP2ujCJRcuQIs5r1FaQ64S7vEVmfHP2SbKzBWTVDA0JDrfHzVD?=
 =?us-ascii?Q?5GTjYftbMRuLrX4a9ukn+yKn79FeGg8jhbozeTULacGfVHiEGFUH4QA6A2od?=
 =?us-ascii?Q?OffceZDonZKm1DIYLlq2nCUm+SnbwBz6fHGap3i2ahTU3YXE+d9e+pix807v?=
 =?us-ascii?Q?8DNiVWXYXtpEbkwJOCt+kW+tgKiGnbrbJZ3YasGIYNmG9pQbi0fm23zDYQvH?=
 =?us-ascii?Q?J8q7JaejpxJa4/r+dzB3EtE3QlVeF+ayzE+CAJF8hJqpFg2wbAIp2SuIMz92?=
 =?us-ascii?Q?FNlixN39a1Gh8M7lHqZPM4K2asKw9gq4wcQhGH4UEkNuviVJFRt0pUs40fSd?=
 =?us-ascii?Q?uPlPZbL17XOYiYYPqynHUIMHKFIv/yG2zlyV5LVO2pcAZKRc7u2bWLiU2TcA?=
 =?us-ascii?Q?cmVEYmpvs0RhrIpsvXIZaG67caafIWqO/d+RF/gFCR2TRc9sqwDSYgEoI46c?=
 =?us-ascii?Q?I97lgdLdCviJrBMZRG/A0ApAyldVhf8bB0KsezLLsieKTGkNahykiAoFmeW1?=
 =?us-ascii?Q?rio9TsqaupHT7XNPTyLUiQrG6/EF+XkEm49W83zZ53g5V14YQfpu8M/8aAHi?=
 =?us-ascii?Q?w0f5AfByZObSYjn2tOypGOYZgxuASq+gS10JTLS2A/7E9Hk16C/X9qon3/YW?=
 =?us-ascii?Q?l+dow7qEaNmW30P6FeowjPu6jwlpbP2tXlXvrUdEVzOCvlJBdfhA/1zDDYUe?=
 =?us-ascii?Q?a8+KEg+G3Z0XYSP0+d7fRGVaKtLC/rYkuVFcRzQUSZ5p1GD9vH9qMphPw0qA?=
 =?us-ascii?Q?oeB1RGF5GLu7JqwVTZOXjAcgvv+IVniRcPebcnDpSZ4hrP5djjPvEVnkzHch?=
 =?us-ascii?Q?hA9BcTYH+ReCox0gpw+0f8BR/P7ZARWmmUmdSSWcPtnMyvSa1QDRT9ihMU/S?=
 =?us-ascii?Q?iJO23WP3k6kIyLbh+UCuOyy9NLH5j9xU4VTXqSVERc77FYQQWoBpRsgNTZUP?=
 =?us-ascii?Q?4vvst58Elyo30EFP+ex7QBk3fhL3YxSpcc4k8a00kp7Tuj9WPtQWCrPnoxfW?=
 =?us-ascii?Q?/2ZwySdOjQtUdnGWYNf+m4v8cRt1Qo/IA38eLLMl00XbeEtOnBRvTf6gOfYU?=
 =?us-ascii?Q?FFyV3EO6X9mmu910e/9nJz3UkszIaMRl63cK+3rRcDvLfvuNnTe+9o2cqbBt?=
 =?us-ascii?Q?LoJ7BvOxPDZGce8iEYRFD5Ywa1kvNatDhsw1CJ7/GyZhxBcE+E/Lb9eeVGc6?=
 =?us-ascii?Q?dItr3LmbmPxXgTqJf+lMZ30rRrVcO+AkXBOl2oKRvvxdcC1KcBAkzvxvMECf?=
 =?us-ascii?Q?hIcCFzfkKGADgeu/nvaEF/ZKJVSOJRyQNhoInc0JDsMbSsG6pJMGBUYN4rI+?=
 =?us-ascii?Q?DKk7h99KbkK3qMzewKh/BxsEHfHC0UfkPolhd2CfwyAQB9zt3xwxkpanbEqm?=
 =?us-ascii?Q?7hCAIj8EUEUSLb3G0FFswZZDvEwVNrQdWCtlF7mzacvkMHozzueGcGYKu4cf?=
 =?us-ascii?Q?yabb8O3UX8fJqxucst1lycDoTh+1P898kxQKfUD6XqTuEG9PYq0fGFNAmo74?=
 =?us-ascii?Q?WgHz5JWGrYlXYwmhZWoJQZh9MO24un6AFjoydOU1iavNVKnnxdV39nphL7Dz?=
 =?us-ascii?Q?TIJDawO3CIiNoaR+1Wi3xkDpmbIbMFg4y9hiDTG1gkNkIevPafkl8YkDojrg?=
 =?us-ascii?Q?Eg=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?us-ascii?Q?cbhzsK0xaad0AA3P3higq97VyVR4/85kRxE6pPRnxdWZk5KZeZAEhTtmiRcy?=
 =?us-ascii?Q?WUrCCDPVerjU8jybN8NPum3oPkJtoLaBI/dNrii4DNCKttoslI2lkywFgB/C?=
 =?us-ascii?Q?+OHvBcpwjI8p8kzhuF5e8o5vm1yPjcP1e73UaqdB2MvGiQtyf0ApCewEi51Y?=
 =?us-ascii?Q?lGLwOY98/TEHO8ywuTwWnkepzHwbzzR34XCOUilI7/Ia3bOqEF95oeBF4wOY?=
 =?us-ascii?Q?9vNOjd8n6IuXF9EBii8Kwrl8zJheU65m6Z1ydbB6LV4Z1aG4aAjgZdRvHkTK?=
 =?us-ascii?Q?McFYcke11K3V2gihsBqXauE+WrKmN31EgprRinf6OUkdydH9fjVuU5pH80BD?=
 =?us-ascii?Q?RWwBJnaL+T8fmymcgf6tWY+X6S52daEl1S1rOmjW2boRlS/Infy2BEiTjQ/K?=
 =?us-ascii?Q?VcMgGGr835VQABG4WsMup2Uw0mCITdtVhX7DmJznJU1EtbQNNNoL6MS1i8ZD?=
 =?us-ascii?Q?H2yaQGlZdjm1bIOWOeA7RrNuCXLO1c+zB8Gk2XOhGseW0g1GLVpJnLGQ6NIU?=
 =?us-ascii?Q?cMi7HnU67mI15ONn5JemNa7qNZXh6jKD9MmKkatpJhOb4ju0HQ+Y2TrY+bFQ?=
 =?us-ascii?Q?LmC/9tPj8W9/SkcRt6pyrB9/MUEkMSMUQFT3JPuFL8XURurPb3o4p0jW3ylJ?=
 =?us-ascii?Q?rCXq4J0rT8zXOgJlwT6jRdCD+YZIMG7sVTWYG4/S6WwAG3Rrg5Worn8MDYFN?=
 =?us-ascii?Q?YKWqIA+IXtfQGJQji72nrVPUWlFci2x9HN2+eOVkuHc4pz80ZUMTCDq/mB4+?=
 =?us-ascii?Q?oz0R+T6NPPh0/iSLuHkJj0VwexKV7eEbrSK67i6JbsB96vpICWiIneMhaWPs?=
 =?us-ascii?Q?/xwV9qhcH9beODQ1z9ufOqHgHVIUB9jyg9NFr4hOkMqq0iAKPIPhA3K4gVoX?=
 =?us-ascii?Q?d+AY4gt2SQzFdTQ1ok0VAsLZ5S7N8FNqwXrZX85K1Tn+pPYvQtjxqE2I5exY?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e03c0253-48a9-4687-65a8-08db39c13307
X-MS-Exchange-CrossTenant-AuthSource: SN6PR10MB3022.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Apr 2023 12:43:35.1710
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: KHIyaalHqXXj5/4NSouvZFDDMJNmRcWXseOs5bSgoqgSmm/10G5ADKgnr+Lo3zPMoRSVaa+LTXD/VjH2nzqLeA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR10MB4165
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22
 definitions=2023-04-10_08,2023-04-06_03,2023-02-09_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999
 phishscore=0 mlxscore=0 malwarescore=0 suspectscore=0 bulkscore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2303200000 definitions=main-2304100106
X-Proofpoint-GUID: zs-WJl6qfq4VxfWgLJVIgUppOYY7aBDj
X-Proofpoint-ORIG-GUID: zs-WJl6qfq4VxfWgLJVIgUppOYY7aBDj
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
        DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,
        SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

* Peng Zhang <zhangpeng.00@bytedance.com> [230407 00:10]:
> In mas_alloc_nodes(), there is such a piece of code:
> while (requested) {
> 	...
> 	node->node_count = 0;
> 	...
> }

You don't need to quote code in your commit message since it is
available in the change log or in the file itself.

> "node->node_count = 0" means to initialize the node_count field of the
> new node, but the node may not be a new node. It may be a node that
> existed before and node_count has a value, setting it to 0 will cause a
> memory leak. At this time, mas->alloc->total will be greater than the
> actual number of nodes in the linked list, which may cause many other
> errors. For example, out-of-bounds access in mas_pop_node(), and
> mas_pop_node() may return addresses that should not be used.
> Fix it by initializing node_count only for new nodes.
> 
> Fixes: 54a611b60590 ("Maple Tree: add new data structure")
> Signed-off-by: Peng Zhang <zhangpeng.00@bytedance.com>
> Cc: <stable@vger.kernel.org>
> ---
>  lib/maple_tree.c | 16 ++++------------
>  1 file changed, 4 insertions(+), 12 deletions(-)
> 
> diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> index 65fd861b30e1..9e25b3215803 100644
> --- a/lib/maple_tree.c
> +++ b/lib/maple_tree.c
> @@ -1249,26 +1249,18 @@ static inline void mas_alloc_nodes(struct ma_state *mas, gfp_t gfp)
>  	node = mas->alloc;
>  	node->request_count = 0;
>  	while (requested) {
> -		max_req = MAPLE_ALLOC_SLOTS;
> -		if (node->node_count) {
> -			unsigned int offset = node->node_count;
> -
> -			slots = (void **)&node->slot[offset];
> -			max_req -= offset;
> -		} else {
> -			slots = (void **)&node->slot;
> -		}
> -
> +		max_req = MAPLE_ALLOC_SLOTS - node->node_count;
> +		slots = (void **)&node->slot[node->node_count];

Thanks, this is much cleaner.

>  		max_req = min(requested, max_req);
>  		count = mt_alloc_bulk(gfp, max_req, slots);
>  		if (!count)
>  			goto nomem_bulk;
>  
> +		if (node->node_count == 0)
> +			node->slot[0]->node_count = 0;
>  		node->node_count += count;
>  		allocated += count;
>  		node = node->slot[0];
> -		node->node_count = 0;
> -		node->request_count = 0;

Why are we not clearing request_count anymore?

>  		requested -= count;
>  	}
>  	mas->alloc->total = allocated;
> -- 
> 2.20.1
>