Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp2206155pxb; Fri, 25 Mar 2022 13:02:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzUlOgvXKjA7faJwY9saFEEL+LKfUpGTH/NkCy8DLBs22JGWvgeGL6k04R4mAgupl65RBVQ X-Received: by 2002:a17:902:dac1:b0:154:4899:85fa with SMTP id q1-20020a170902dac100b00154489985famr13147393plx.88.1648238545471; Fri, 25 Mar 2022 13:02:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648238545; cv=none; d=google.com; s=arc-20160816; b=T+RtznUvxTutiFm19wJeUO47R/33MkDEX0WqdqLYzFVCkJvqWLlCeAIddaezrLdN6L IY85Y1lRs9N3pAdMDDT4e0ysgyM0PklctBAm1B5DFkLnzVd+SABf7RRNE18B3MJ2Yso2 4kSzV7NaF7AG4xquYArzIi8jpICQre1a1r2MmNzKIrePg/7/nINzxbdfP3wmfuWxDjZN yfGoA6PkaU7+buxu3zSS9j1rC5M3l0SL3QK7yDgcyLqQtjjQ182Cc5oHTTCIZ6emBAwx ksOPC9tHIoioh9eE4YUqDm3fXDRUZ/MyjOOdzgfl96ZBxTt0kIL7G7j+ezYwT5dVCK8T fpGQ== 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=MKukOVoCcojho/J7qoX2iqlpUXyDJWYTcOmlUuE3d0I=; b=ECOmtZy+7+Y88bWX3/ZWUuePK6vZO3oggKLewWXd9eCvKTsrso/eknsaoy26SUG/qu sNNb+9gh4L7mHeA7kymSjkQDiovlootKNzCAJ0rHNeOJtJdwXZ3Zq2sZTDj42/ajtnoh bXql374wUbq3TrQnw31gElMYaNFXZcFyF5Kd1/H9uMPHzZ/SQuZeIt6L4qIZdZNssMUZ N3k5o7fH9Ozgs3bu0RhyJu0o1elyDSLKUdzXdKgy2kf/lZDz0f8ZRkIabQLuaN15X16u D+g0gGKSgNuH1tBTXhRFNN1oIi9IZaWQkY/3mwGuusdaBr1jmv9k2wY0fxYdc5wKyu16 HfQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qILMMad5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1: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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id b10-20020a63cf4a000000b003816043efaesi3182313pgj.419.2022.03.25.13.02.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Mar 2022 13:02:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=qILMMad5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1: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: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id B9FD61BA68A; Fri, 25 Mar 2022 11:51:43 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376679AbiCYPXL (ORCPT + 99 others); Fri, 25 Mar 2022 11:23:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376500AbiCYPV0 (ORCPT ); Fri, 25 Mar 2022 11:21:26 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C330E33B2; Fri, 25 Mar 2022 08:16:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0475260AD8; Fri, 25 Mar 2022 15:16:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16197C340E9; Fri, 25 Mar 2022 15:16:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1648221362; bh=GZNRNiIoyZEXnjgDRCav5syAkpR7quuVouyygIjFUaE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qILMMad5jQ7oNNtwZsj5ipPoz4QDokP9wQJwSbUa4I7Mm8/6YIBbgqydngVw6VjcV a8C6bkoHPlTpBCPltrA0hCxf1bKQB47IiqBHtbeHIjWSyxFZdHM3XHTGT1LYAq9bSR diJ7X5lZNxDa0mRMdOg/KxNxPROY4W/P2twdzqoY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Matthias Kretschmer , =?UTF-8?q?Linus=20L=C3=BCssing?= , Johannes Berg Subject: [PATCH 5.15 33/37] mac80211: fix potential double free on mesh join Date: Fri, 25 Mar 2022 16:14:34 +0100 Message-Id: <20220325150420.878913166@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220325150419.931802116@linuxfoundation.org> References: <20220325150419.931802116@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-kernel@vger.kernel.org From: Linus Lüssing commit 4a2d4496e15ea5bb5c8e83b94ca8ca7fb045e7d3 upstream. While commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving mesh") fixed a memory leak on mesh leave / teardown it introduced a potential memory corruption caused by a double free when rejoining the mesh: ieee80211_leave_mesh() -> kfree(sdata->u.mesh.ie); ... ieee80211_join_mesh() -> copy_mesh_setup() -> old_ie = ifmsh->ie; -> kfree(old_ie); This double free / kernel panics can be reproduced by using wpa_supplicant with an encrypted mesh (if set up without encryption via "iw" then ifmsh->ie is always NULL, which avoids this issue). And then calling: $ iw dev mesh0 mesh leave $ iw dev mesh0 mesh join my-mesh Note that typically these commands are not used / working when using wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids the memory corruption, too. The issue was first observed in an application which was not using wpa_supplicant but "Senf" instead, which implements its own calls to nl80211. Fixing the issue by removing the kfree()'ing of the mesh IE in the mesh join function and leaving it solely up to the mesh leave to free the mesh IE. Cc: stable@vger.kernel.org Fixes: 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving mesh") Reported-by: Matthias Kretschmer Signed-off-by: Linus Lüssing Tested-by: Mathias Kretschmer Link: https://lore.kernel.org/r/20220310183513.28589-1-linus.luessing@c0d3.blue Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman --- net/mac80211/cfg.c | 3 --- 1 file changed, 3 deletions(-) --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -2110,14 +2110,12 @@ static int copy_mesh_setup(struct ieee80 const struct mesh_setup *setup) { u8 *new_ie; - const u8 *old_ie; struct ieee80211_sub_if_data *sdata = container_of(ifmsh, struct ieee80211_sub_if_data, u.mesh); int i; /* allocate information elements */ new_ie = NULL; - old_ie = ifmsh->ie; if (setup->ie_len) { new_ie = kmemdup(setup->ie, setup->ie_len, @@ -2127,7 +2125,6 @@ static int copy_mesh_setup(struct ieee80 } ifmsh->ie_len = setup->ie_len; ifmsh->ie = new_ie; - kfree(old_ie); /* now copy the rest of the setup parameters */ ifmsh->mesh_id_len = setup->mesh_id_len;