From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5A63EC4167B for ; Thu, 14 Dec 2023 09:17:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=cWbx5Np5SmC9LzpyoQPtS0JTb/0BiIDjOaLCAArqcys=; b=kcGw17nz1JFNOC MeLahIieU7UfzMPLGCE2cwI+gsLevPsqWv0zQIxD138m8O/qFqz5mY5Co7qqe+BcE24ZCIezSMqEE 9N3WUhaNA16XfJUkCXygPmPwf8o2edlgwmqnKxZz6KqaqGAQDfKiSsBtBXQLOGKqInw4hk9sT66J3 YrHYtJcOllpWAr0VKunRXuk2IhTHIgjjZZIzY+DFfHPSOWF/vwRsLrEFjeWYLx+R3oweCK5aqBb3I Cn4L58pqNK4V/meg8UWFmqPwbBvA/G1irACrAr1E4z8hSv4IPjjbKpsf4JxhEaXZaXogav+Wap3Xb rqGTyFJjnGBoUIttCGaA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rDhqG-00HK4o-0r; Thu, 14 Dec 2023 09:17:16 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rDhqC-00HK2w-0O for kexec@lists.infradead.org; Thu, 14 Dec 2023 09:17:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702545430; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uUDsFrdozAvlpGaxLHtyNeP/OnotbqYqMUVE5yB4sEs=; b=dDfCrwnIyws5JUJ3wyZbqQF6V79VgICboLF3p1EuxQ6w2QeblmBXvlp4hnh+XgHovTr7qA wFU4r/5vWVICvF+36OjQSQeDE3B+IRpSUBdG9jDIzV2+sPuxjP9ZUikLNB8cmpxiK3Ebgc vDCEDkCWzqFt/EPq14oO7oSMQSVzOxE= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-114-5ChW8uqMO92L_niAB7szIw-1; Thu, 14 Dec 2023 04:17:06 -0500 X-MC-Unique: 5ChW8uqMO92L_niAB7szIw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9D7382820B79; Thu, 14 Dec 2023 09:17:05 +0000 (UTC) Received: from localhost (unknown [10.72.116.38]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E2E112026D66; Thu, 14 Dec 2023 09:17:03 +0000 (UTC) Date: Thu, 14 Dec 2023 17:17:00 +0800 From: Baoquan He To: fuqiang wang Cc: Vivek Goyal , Dave Young , kexec@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] kexec: avoid out of bounds in crash_exclude_mem_range() Message-ID: References: <20231127025641.62210-1-fuqiang.wang@easystack.cn> <92a1bdff-e988-48ff-8e78-2998834a3e02@easystack.cn> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <92a1bdff-e988-48ff-8e78-2998834a3e02@easystack.cn> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231214_011712_246185_7AAF9D50 X-CRM114-Status: GOOD ( 41.90 ) X-BeenThere: kexec@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "kexec" Errors-To: kexec-bounces+kexec=archiver.kernel.org@lists.infradead.org T24gMTIvMTMvMjMgYXQgMDk6MTBwbSwgZnVxaWFuZyB3YW5nIHdyb3RlOgo+IOWcqCAyMDIzLzEy LzEzIDEyOjQ0LCBCYW9xdWFuIEhlIOWGmemBkzoKPiAKPiA+IE9uIDExLzMwLzIzIGF0IDA5OjIw cG0sIGZ1cWlhbmcgd2FuZyB3cm90ZToKPiA+ID4gT24gMjAyMy8xMS8zMCAxNTo0NCwgQmFvcXVh biBIZSB3cm90ZToKPiA+ID4gPiBPbiAxMS8yNy8yMyBhdCAxMDo1NmFtLCBmdXFpYW5nIHdhbmcg d3JvdGU6Cj4gPiA+ID4gPiBXaGVuIHRoZSBzcGxpdCBoYXBwZW5lZCwganVkZ2Ugd2hldGhlciBt ZW0tPm5yX3JhbmdlcyBpcyBlcXVhbCB0bwo+ID4gPiA+ID4gbWVtLT5tYXhfbnJfcmFuZ2VzLiBJ ZiBpdCBpcyB0cnVlLCByZXR1cm4gLUVOT01FTS4KPiA+ID4gPiA+IAo+ID4gPiA+ID4gVGhlIGFk dmFudGFnZSBvZiBkb2luZyB0aGlzIGlzIHRoYXQgaXQgY2FuIGF2b2lkIGFycmF5IGJvdW5kcyBj YXVzZWQgYnkKPiA+ID4gPiA+IHNvbWUgYnVncy4gRS5nLiwgQmVmb3JlIGNvbW1pdCA0ODMxYmU3 MDJiOTUgKCJhcm02NC9rZXhlYzogRml4IG1pc3NpbmcKPiA+ID4gPiA+IGV4dHJhIHJhbmdlIGZv ciBjcmFzaGtyZXNfbG93LiIpLCByZXNlcnZlIGJvdGggaGlnaCBhbmQgbG93IG1lbW9yaWVzIGZv cgo+ID4gPiA+ID4gdGhlIGNyYXNoa2VybmVsIG1heSBjYXVzZSBvdXQgb2YgYm91bmRzLgo+ID4g PiA+ID4gCj4gPiA+ID4gPiBPbiB0aGUgb3RoZXIgaGFuZCwgbW92ZSB0aGlzIGNvZGUgYmVmb3Jl IHRoZSBzcGxpdCB0byBlbnN1cmUgdGhhdCB0aGUKPiA+ID4gPiA+IGFycmF5IHdpbGwgbm90IGJl IGNoYW5nZWQgd2hlbiByZXR1cm4gZXJyb3IuCj4gPiA+ID4gSWYgb3V0IG9mIGFycmF5IGJvdW5k YXJ5IGlzIGNhdXNlZCwgbWVhbnMgdGhlIGxhb2RpbmcgZmFpbGVkLCB3aGV0aGVyCj4gPiA+ID4g dGhlIG91dCBvZiBib3VuZGFyeSBoYXBwZW5lZCBvciBub3QuIEkgZG9uJ3Qgc2VlIGhvdyB0aGlz IGNvZGUgY2hhbmdlCj4gPiA+ID4gbWFrZXMgc2Vuc2UuIERvIEkgbWlzcyBhbnl0aGluZz8KPiA+ ID4gPiAKPiA+ID4gPiBUaGFua3MKPiA+ID4gPiBCYW9xdWFuCj4gPiA+ID4gCj4gPiA+IEhpIGJh b3F1YW4sCj4gPiA+IAo+ID4gPiBJbiBzb21lIGNvbmZpZ3VyYXRpb25zLCBvdXQgb2YgYm91bmRz IG1heSBub3QgY2F1c2UgY3Jhc2hfZXhjbHVkZV9tZW1fcmFuZ2UoKQo+ID4gPiByZXR1cm5zIGVy cm9yLCB0aGVuIHRoZSBsb2FkIHdpbGwgc3VjY2VlZC4KPiA+ID4gCj4gPiA+IEUuZy4KPiA+ID4g VGhlcmUgaXMgYSBjbWVtIGJlZm9yZSBleGVjdXRlIGNyYXNoX2V4Y2x1ZGVfbWVtX3JhbmdlKCk6 Cj4gPiA+IAo+ID4gPiAgwqAgY21lbSA9IHsKPiA+ID4gIMKgwqDCoCBtYXhfbnJfcmFuZ2VzID0g Mwo+ID4gPiAgwqDCoMKgIG5yX3JhbmdlcyA9IDIKPiA+ID4gIMKgwqDCoCByYW5nZXMgPSB7Cj4g PiA+ICDCoMKgwqDCoMKgwqAge3N0YXJ0ID0gMSzCoMKgwqDCoMKgIGVuZCA9IDEwMDB9Cj4gPiA+ ICDCoMKgwqDCoMKgwqAge3N0YXJ0ID0gMTAwMSzCoMKgwqAgZW5kID0gMjAwMH0KPiA+ID4gIMKg wqDCoCB9Cj4gPiA+ICDCoCB9Cj4gPiA+IAo+ID4gPiBBZnRlciBleGVjdXRpbmcgdHdpY2UgY3Jh c2hfZXhjbHVkZV9tZW1fcmFuZ2UoKSB3aXRoIHRoZSBzdGFydC9lbmQgcGFyYW1zCj4gPiA+IDEw MC8yMDAsIDMwMC80MDAgcmVzcGVjdGl2ZWx5LCB0aGUgY21lbSB3aWxsIGJlOgo+ID4gPiAKPiA+ ID4gIMKgIGNtZW0gPSB7Cj4gPiA+ICDCoMKgwqAgbWF4X25yX3JhbmdlcyA9IDMKPiA+ID4gIMKg wqDCoCBucl9yYW5nZXMgPSA0wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg PD09IG5yX3JhbmdlcyA+IG1heF9ucl9yYW5nZXMKPiA+ID4gIMKgwqDCoCByYW5nZXMgPSB7Cj4g PiA+ICDCoMKgwqDCoMKgIHtzdGFydCA9IDEswqDCoMKgwqDCoMKgIGVuZCA9IDk5wqAgfQo+ID4g PiAgwqDCoMKgwqDCoCB7c3RhcnQgPSAyMDEswqDCoMKgwqAgZW5kID0gMjk5IH0KPiA+ID4gIMKg wqDCoMKgwqAge3N0YXJ0ID0gNDAxLMKgwqDCoMKgIGVuZCA9IDEwMDB9Cj4gPiA+ICDCoMKgwqDC oMKgIHtzdGFydCA9IDEwMDEswqDCoMKgIGVuZCA9IDIwMDB9wqAgPD09IE9VVCBPRiBCT1VORFMK PiA+ID4gIMKgwqDCoCB9Cj4gPiA+ICDCoCB9Cj4gPiA+IAo+ID4gPiBXaGVuIGFuIG91dCBvZiBi b3VuZHMgb2NjdXJzIGR1cmluZyB0aGUgc2Vjb25kIGV4ZWN1dGlvbiwgdGhlIGZ1bmN0aW9uIHdp bGwgbm90Cj4gPiA+IHJldHVybiBlcnJvci4KPiA+ID4gCj4gPiA+IEFkZGl0aW9uYWxseSwgd2hl biB0aGUgZnVuY3Rpb24gcmV0dXJucyBlcnJvciwgbWVhbnMgdGhlIGxvYWQgZmFpbGVkLiBJdCBz ZWVtcwo+ID4gPiBtZWFuaW5nbGVzcyB0byBrZWVwIHRoZSBvcmlnaW5hbCBkYXRhIHVuY2hhbmdl ZC4gQnV0IGluIG15IG9waW5pb24sIHRoaXMgd2lsbAo+ID4gPiBtYWtlIHRoaXMgZnVuY3Rpb24g bW9yZSByaWdvcm91cyBhbmQgbW9yZSB2ZXJzYXRpbGUuIChIb3dldmVyLCBJIGFtIG5vdCBzdXJl IGlmCj4gPiA+IGl0IGlzIHNlbGYtZGVmZWF0aW5nIGFuZCBJIGhvcGUgdG8gcmVjZWl2ZSBtb3Jl IHN1Z2dlc3Rpb25zKS4KPiA+IFNvcnJ5IGZvciBsYXRlIHJlcGx5Lgo+ID4gCj4gPiBJIGNoZWNr ZWQgdGhlIGNvZGUgYWdhaW4sIHRoZXJlIHNlZW1zIHRvIGJlIGNhc2VzIG91dCBvZiBib3VuZHMg b2NjdXIKPiA+IHZlcnkgcG9zc2libGx5LiBXZSBtYXkgbmVlZCB0byBlbmxhcmdlIHRoZSBjbWVt IGFycmF5IHRvIGF2b2lkIHRoZSByaXNrLgo+ID4gCj4gPiBJbiBiZWxvdyBkcmFmdCBjb2RlLCB3 ZSBuZWVkIGFkZCBhbm90aGVyIHNsb3QgdG8gZXhjbHVkZSB0aGUgbG93IDFNIGFyZWEKPiA+IHdo ZW4gcHJlcGFyaW5nIGVsZmNvcmVoZHIuIEFuZCB0byBleGNsdWRlIHRoZSBlbGYgaGVhZGVyIHJl Z2lvbiBmcm9tCj4gPiBjcmFzaCBrZXJuZWwgcmVnaW9uLCB3ZSBuZWVkIGNyZWF0ZSB0aGUgY21l bSB3aXRoIDIgc2xvdHMuCj4gPiAKPiA+IFdpdGggdGhlc2UgY2hhbmdlLCB3ZSBjYW4gYWJzb2x1 dGVseSBhdm9pZCBvdXQgb2YgYm91bmRzIG9jY3VyZW5jZS4KPiA+IFdoYXQgZG8geW91IHRoaW5r Pwo+ID4gCj4gPiBkaWZmIC0tZ2l0IGEvYXJjaC94ODYva2VybmVsL2NyYXNoLmMgYi9hcmNoL3g4 Ni9rZXJuZWwvY3Jhc2guYwo+ID4gaW5kZXggMTcxNWU1ZjA2YTU5Li4yMWZhY2FiY2Y2OTkgMTAw NjQ0Cj4gPiAtLS0gYS9hcmNoL3g4Ni9rZXJuZWwvY3Jhc2guYwo+ID4gKysrIGIvYXJjaC94ODYv a2VybmVsL2NyYXNoLmMKPiA+IEBAIC0xNDcsMTAgKzE0NywxMCBAQCBzdGF0aWMgc3RydWN0IGNy YXNoX21lbSAqZmlsbF91cF9jcmFzaF9lbGZfZGF0YSh2b2lkKQo+ID4gICAJCXJldHVybiBOVUxM Owo+ID4gICAJLyoKPiA+IC0JICogRXhjbHVzaW9uIG9mIGNyYXNoIHJlZ2lvbiBhbmQvb3IgY3Jh c2hrX2xvd19yZXMgbWF5IGNhdXNlCj4gPiAtCSAqIGFub3RoZXIgcmFuZ2Ugc3BsaXQuIFNvIGFk ZCBleHRyYSB0d28gc2xvdHMgaGVyZS4KPiA+ICsJICogRXhjbHVzaW9uIG9mIGxvdyAxTSwgY3Jh c2ggcmVnaW9uIGFuZC9vciBjcmFzaGtfbG93X3JlcyBtYXkKPiA+ICsJICogY2F1c2UgYW5vdGhl ciByYW5nZSBzcGxpdC4gU28gYWRkIGV4dHJhIHR3byBzbG90cyBoZXJlLgo+ID4gICAJICovCj4g PiAtCW5yX3JhbmdlcyArPSAyOwo+ID4gKwlucl9yYW5nZXMgKz0gMzsKPiA+ICAgCWNtZW0gPSB2 emFsbG9jKHN0cnVjdF9zaXplKGNtZW0sIHJhbmdlcywgbnJfcmFuZ2VzKSk7Cj4gPiAgIAlpZiAo IWNtZW0pCj4gPiAgIAkJcmV0dXJuIE5VTEw7Cj4gSGkgYmFvcXVhbiwKPiAKPiBFeGNsdXNpb24g b2YgbG93IDFNIG1heSBub3QgY2F1c2UgbmV3IHJlZ2lvbi4gQmVjYXVzZSB3aGVuIGNhbGxpbmcK PiBjcmFzaF9leGNsdWRlX21lbV9yYW5nZSgpLCB0aGUgc3RhcnQgcGFyYW1ldGVyIGlzIDAgYW5k IHRoZSBjb25kaXRpb24gZm9yCj4gc3BsaXR0aW5nIGEgbmV3IHJlZ2lvbiBpcyB0aGF0IHRoZSBz dGFydCwgZW5kIHBhcmFtZXRlcnMgYXJlIGJvdGggaW4gYSBjZXJ0YWluCj4gZXhpc3RpbmcgcmVn aW9uIGluIGNtZW0gYW5kIGNhbm5vdCBiZSBlcXVhbCB0byBleGlzdGluZyByZWdpb24ncyBzdGFy dCBvciBlbmQuCj4gT2J2aW91c2x5LCBzdGFydCAoMCkgY2Fubm90IG1lZXQgdGhpcyBjb25kaXRp b24uCgpPSywgdGhpcyBpcyBhbiBzcGVjaWFsIGNhc2UuCgo+ID4gQEAgLTI4Miw3ICsyODIsNyBA QCBpbnQgY3Jhc2hfc2V0dXBfbWVtbWFwX2VudHJpZXMoc3RydWN0IGtpbWFnZSAqaW1hZ2UsIHN0 cnVjdCBib290X3BhcmFtcyAqcGFyYW1zKQo+ID4gICAJc3RydWN0IGNyYXNoX21lbW1hcF9kYXRh IGNtZDsKPiA+ICAgCXN0cnVjdCBjcmFzaF9tZW0gKmNtZW07Cj4gPiAtCWNtZW0gPSB2emFsbG9j KHN0cnVjdF9zaXplKGNtZW0sIHJhbmdlcywgMSkpOwo+ID4gKwljbWVtID0gdnphbGxvYyhzdHJ1 Y3Rfc2l6ZShjbWVtLCByYW5nZXMsIDIpKTsKPiA+ICAgCWlmICghY21lbSkKPiA+ICAgCQlyZXR1 cm4gLUVOT01FTTsKPiA+IAo+IFllcywgeW91IGFyZSByaWdodC4gRXhjbHVkZSB0aGUgZWxmIGhl YWRlciByZWdpb24gZnJvbSBjcmFzaCBrZXJuZWwgcmVnaW9uIG1heQo+IGNhdXNlIHNwbGl0IGEg bmV3IHJlZ2lvbi4gQW5kIHRoZXJlIHNlZW1zIHRvIGJlIGFub3RoZXIgaXNzdWUgd2l0aCB0aGlz IGNvZGUKPiBwYXRoOiBCZWZvcmUgY2FsbGluZyBjcmFzaF9leGNsdWRlX21lbV9yYW5nZSgpLCBj bWVtLT5tYXhfbnJfcmFuZ2VzIHdhcyBub3QKPiBpbml0aWFsaXplZC4KClllYWgsIHRoZSBpbml0 IG5lZWQgYmUgYWRkZWQuCgo+IAo+IEluIG15IG9waW5pb24sIHRoZXNlIGNoYW5nZSBjYW4gYWJz b2x1dGVseSBhdm9pZCBvdXQgb2YgYm91bmRzIG9jY3VyZW5jZS4gQnV0Cj4gd2hlbiB3ZSBmb3Jn ZXQgdG8gbW9kaWZ5IG1heF9ucl9yYW5nZXMgZHVlIHRvIGEgbWlzdGFrZXMgaW4gdGhlIGZ1dHVy ZSwgaXMgaXQKPiBiZXR0ZXIgdG8gcmVwb3J0IGl0IGJ5IHJldHVybmluZyBhbiBlcnJvciB0aHJv dWdoIGNyYXNoX2V4Y2x1ZGVfbWVtX3JhbmdlKCkuCj4gV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQg aXQ/CgpJIGRvbid0IHNlZSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHlvdXIgcGF0Y2ggYW5kIHRo ZSBjdXJyZW50IGNvZGUuClBsZWFzZSBzZWUgbXkgY29tbWVudCBpbiB5b3VyIGVhcmxpZXIgZXhh bXBsZS4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpr ZXhlYyBtYWlsaW5nIGxpc3QKa2V4ZWNAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMu aW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2tleGVjCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04798C4332F for ; Thu, 14 Dec 2023 09:17:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234531AbjLNJRD (ORCPT ); Thu, 14 Dec 2023 04:17:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229691AbjLNJRC (ORCPT ); Thu, 14 Dec 2023 04:17:02 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27DA110F for ; Thu, 14 Dec 2023 01:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702545427; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uUDsFrdozAvlpGaxLHtyNeP/OnotbqYqMUVE5yB4sEs=; b=D0pa7oyvyZlNdsd4L4PqeHpai8H8M8jjqqbNH36+LChBXw90vG+F0C6ui+u1FuSoKWZjDT 0nS95XA0pc1T3c1NqnNC0T06FwHNlxkr10+vPrzci8SF5T53Dsfo7ntP/jgnhtFQ8Z4Xek NZewtkeRXXtsrsrNH8E31P44OCB4UXg= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-114-5ChW8uqMO92L_niAB7szIw-1; Thu, 14 Dec 2023 04:17:06 -0500 X-MC-Unique: 5ChW8uqMO92L_niAB7szIw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9D7382820B79; Thu, 14 Dec 2023 09:17:05 +0000 (UTC) Received: from localhost (unknown [10.72.116.38]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E2E112026D66; Thu, 14 Dec 2023 09:17:03 +0000 (UTC) Date: Thu, 14 Dec 2023 17:17:00 +0800 From: Baoquan He To: fuqiang wang Cc: Vivek Goyal , Dave Young , kexec@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] kexec: avoid out of bounds in crash_exclude_mem_range() Message-ID: References: <20231127025641.62210-1-fuqiang.wang@easystack.cn> <92a1bdff-e988-48ff-8e78-2998834a3e02@easystack.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <92a1bdff-e988-48ff-8e78-2998834a3e02@easystack.cn> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/13/23 at 09:10pm, fuqiang wang wrote: > 在 2023/12/13 12:44, Baoquan He 写道: > > > On 11/30/23 at 09:20pm, fuqiang wang wrote: > > > On 2023/11/30 15:44, Baoquan He wrote: > > > > On 11/27/23 at 10:56am, fuqiang wang wrote: > > > > > When the split happened, judge whether mem->nr_ranges is equal to > > > > > mem->max_nr_ranges. If it is true, return -ENOMEM. > > > > > > > > > > The advantage of doing this is that it can avoid array bounds caused by > > > > > some bugs. E.g., Before commit 4831be702b95 ("arm64/kexec: Fix missing > > > > > extra range for crashkres_low."), reserve both high and low memories for > > > > > the crashkernel may cause out of bounds. > > > > > > > > > > On the other hand, move this code before the split to ensure that the > > > > > array will not be changed when return error. > > > > If out of array boundary is caused, means the laoding failed, whether > > > > the out of boundary happened or not. I don't see how this code change > > > > makes sense. Do I miss anything? > > > > > > > > Thanks > > > > Baoquan > > > > > > > Hi baoquan, > > > > > > In some configurations, out of bounds may not cause crash_exclude_mem_range() > > > returns error, then the load will succeed. > > > > > > E.g. > > > There is a cmem before execute crash_exclude_mem_range(): > > > > > >   cmem = { > > >     max_nr_ranges = 3 > > >     nr_ranges = 2 > > >     ranges = { > > >        {start = 1,      end = 1000} > > >        {start = 1001,    end = 2000} > > >     } > > >   } > > > > > > After executing twice crash_exclude_mem_range() with the start/end params > > > 100/200, 300/400 respectively, the cmem will be: > > > > > >   cmem = { > > >     max_nr_ranges = 3 > > >     nr_ranges = 4                    <== nr_ranges > max_nr_ranges > > >     ranges = { > > >       {start = 1,       end = 99  } > > >       {start = 201,     end = 299 } > > >       {start = 401,     end = 1000} > > >       {start = 1001,    end = 2000}  <== OUT OF BOUNDS > > >     } > > >   } > > > > > > When an out of bounds occurs during the second execution, the function will not > > > return error. > > > > > > Additionally, when the function returns error, means the load failed. It seems > > > meaningless to keep the original data unchanged. But in my opinion, this will > > > make this function more rigorous and more versatile. (However, I am not sure if > > > it is self-defeating and I hope to receive more suggestions). > > Sorry for late reply. > > > > I checked the code again, there seems to be cases out of bounds occur > > very possiblly. We may need to enlarge the cmem array to avoid the risk. > > > > In below draft code, we need add another slot to exclude the low 1M area > > when preparing elfcorehdr. And to exclude the elf header region from > > crash kernel region, we need create the cmem with 2 slots. > > > > With these change, we can absolutely avoid out of bounds occurence. > > What do you think? > > > > diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c > > index 1715e5f06a59..21facabcf699 100644 > > --- a/arch/x86/kernel/crash.c > > +++ b/arch/x86/kernel/crash.c > > @@ -147,10 +147,10 @@ static struct crash_mem *fill_up_crash_elf_data(void) > > return NULL; > > /* > > - * Exclusion of crash region and/or crashk_low_res may cause > > - * another range split. So add extra two slots here. > > + * Exclusion of low 1M, crash region and/or crashk_low_res may > > + * cause another range split. So add extra two slots here. > > */ > > - nr_ranges += 2; > > + nr_ranges += 3; > > cmem = vzalloc(struct_size(cmem, ranges, nr_ranges)); > > if (!cmem) > > return NULL; > Hi baoquan, > > Exclusion of low 1M may not cause new region. Because when calling > crash_exclude_mem_range(), the start parameter is 0 and the condition for > splitting a new region is that the start, end parameters are both in a certain > existing region in cmem and cannot be equal to existing region's start or end. > Obviously, start (0) cannot meet this condition. OK, this is an special case. > > @@ -282,7 +282,7 @@ int crash_setup_memmap_entries(struct kimage *image, struct boot_params *params) > > struct crash_memmap_data cmd; > > struct crash_mem *cmem; > > - cmem = vzalloc(struct_size(cmem, ranges, 1)); > > + cmem = vzalloc(struct_size(cmem, ranges, 2)); > > if (!cmem) > > return -ENOMEM; > > > Yes, you are right. Exclude the elf header region from crash kernel region may > cause split a new region. And there seems to be another issue with this code > path: Before calling crash_exclude_mem_range(), cmem->max_nr_ranges was not > initialized. Yeah, the init need be added. > > In my opinion, these change can absolutely avoid out of bounds occurence. But > when we forget to modify max_nr_ranges due to a mistakes in the future, is it > better to report it by returning an error through crash_exclude_mem_range(). > What do you think about it? I don't see the difference between your patch and the current code. Please see my comment in your earlier example.