[Regression] Cannot overwrite VID header offset any more [Was: [PATCH] ubi: ensure that VID header offset + VID header size <= alloc, size]
Message ID | 20230417160102.lw6n7bdxwrlkluwj@pengutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2239489vqo; Mon, 17 Apr 2023 09:12:41 -0700 (PDT) X-Google-Smtp-Source: AKy350ZGcuzch0ZavWHcBAJwFKseJR8IhMZuxU6c3rrVEanWNhkSWQHHZzi0UBzRJGoDtd7nnZ+Z X-Received: by 2002:a05:6808:11cc:b0:38c:7a71:d4dc with SMTP id p12-20020a05680811cc00b0038c7a71d4dcmr4569565oiv.49.1681747960710; Mon, 17 Apr 2023 09:12:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681747960; cv=none; d=google.com; s=arc-20160816; b=XNOgCbj4mAl1aPNh3gQ0Gr0eNw3Z9hGsXKRql2BwMM65Hz6iRHIvVHH1oGY1rWG0Jm N0DHP+J3G3fQJuEAg41qOd6axThasSzc7w+ycBlkiqanaTibGNrZdkt6tgFRxqHdlTEo XPzG3vrYo7RKqDjXY8QGiNYcXQYtS0D9ow74vtqbjojsY+9iwgYcrYy1zBSy154WGwZY BXFczSPF7v2I7/SL744+cmn7Nc0lv5rE2A34uNn74s8H+EQ+rI0CE9rnGVxZ0w3zzXdg N4pmA84U9ZaZ5jMDIyBfgH9qvl4HdaLkM2dKwjpL1hEZZAoor2N3tbVxygd3TPb/8OU5 Vu6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=kGmyDQlelOrTQcbGerKEwktzWkImX7rpSMF66OYL4SU=; b=H2eg2CcoPdMvohIzMZ2swwLIWHzW4u3qncdTtnRQHv8t7O/KuHspV1iF47KjlSkBOJ +vs1HZH6CkZ9iG4Z1I/yN7INinO0H2HLFS4TYZBZwwz45V0rLbMRtsUX/dJNdoPyaAG+ vFiQ18HLtsNcHGzpGqU8hBjtCRaumS/VTbPk5iGpG3Tj0lYE6YeHqlnRkuw7YpRUP5vx 7UIHQhOtg/WIMzm4CF8O2un/ewwYvCJ0CxVd1VYt0V7+EZ+YqnQAWinOu6nd0r1hUNWc 8C4sq3I3mCUAegl8B3+SAzBXCUfFjZ1L0gpm7qSP+MK0U4kffF/SkGMOc9rTCavAZSCh MncQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e3-20020a056820060300b00517665db551si11354092oow.27.2023.04.17.09.12.26; Mon, 17 Apr 2023 09:12:40 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230168AbjDQQBZ (ORCPT <rfc822;leviz.kernel.dev@gmail.com> + 99 others); Mon, 17 Apr 2023 12:01:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229713AbjDQQBX (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 17 Apr 2023 12:01:23 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E6A8184 for <linux-kernel@vger.kernel.org>; Mon, 17 Apr 2023 09:01:22 -0700 (PDT) Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <ukl@pengutronix.de>) id 1poRHt-00055n-V1; Mon, 17 Apr 2023 18:01:05 +0200 Received: from [2a0a:edc0:0:900:1d::77] (helo=ptz.office.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtp (Exim 4.94.2) (envelope-from <ukl@pengutronix.de>) id 1poRHr-00BuXB-Ko; Mon, 17 Apr 2023 18:01:03 +0200 Received: from ukl by ptz.office.stw.pengutronix.de with local (Exim 4.94.2) (envelope-from <ukl@pengutronix.de>) id 1poRHq-00DyP0-TH; Mon, 17 Apr 2023 18:01:02 +0200 Date: Mon, 17 Apr 2023 18:01:02 +0200 From: Uwe =?utf-8?q?Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de> To: George Kennedy <george.kennedy@oracle.com> Cc: richard@nod.at, miquel.raynal@bootlin.com, vigneshr@ti.com, eorge.kennedy@oracle.com, linux-mtd@lists.infradead.org, syzkaller@googlegroups.com, linux-kernel@vger.kernel.org, harshit.m.mogalapalli@oracle.com, kernel@pengutronix.de, stable@vger.kernel.org Subject: [Regression] Cannot overwrite VID header offset any more [Was: [PATCH] ubi: ensure that VID header offset + VID header size <= alloc, size] Message-ID: <20230417160102.lw6n7bdxwrlkluwj@pengutronix.de> References: <ae901608-0580-010a-26e3-99d0b704b88b@oracle.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vrholj4gzneqir3b" Content-Disposition: inline In-Reply-To: <ae901608-0580-010a-26e3-99d0b704b88b@oracle.com> X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763440182535878556?= X-GMAIL-MSGID: =?utf-8?q?1763440549726549295?= |
Series |
[Regression] Cannot overwrite VID header offset any more [Was: [PATCH] ubi: ensure that VID header offset + VID header size <= alloc, size]
|
|
Commit Message
Uwe Kleine-König
April 17, 2023, 4:01 p.m. UTC
Hello, On Tue, Nov 15, 2022 at 10:14:44AM -0500, George Kennedy wrote: > Ensure that the VID header offset + VID header size does not exceed > the allocated area to avoid slab OOB. > > BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline] > BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline] > BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197 > Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555 > > CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W > 6.0.0-1868 #1 > Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29 > 04/01/2014 > Call Trace: > <TASK> > __dump_stack lib/dump_stack.c:88 [inline] > dump_stack_lvl+0x85/0xad lib/dump_stack.c:106 > print_address_description mm/kasan/report.c:317 [inline] > print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433 > kasan_report+0xa7/0x11b mm/kasan/report.c:495 > crc32_body lib/crc32.c:111 [inline] > crc32_le_generic lib/crc32.c:179 [inline] > crc32_le_base+0x58c/0x626 lib/crc32.c:197 > ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c:1067 > create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317 > create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline] > ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 > ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 > ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 > ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 > vfs_ioctl fs/ioctl.c:51 [inline] > __do_sys_ioctl fs/ioctl.c:870 [inline] > __se_sys_ioctl fs/ioctl.c:856 [inline] > __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0x0 > RIP: 0033:0x7f96d5cf753d > Code: > RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d > RDX: 0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003 > RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0 > R13: 00007fffd72207e0 R14: 0000000000000000 R15: 0000000000000000 > </TASK> > > Allocated by task 1555: > kasan_save_stack+0x20/0x3d mm/kasan/common.c:38 > kasan_set_track mm/kasan/common.c:45 [inline] > set_alloc_info mm/kasan/common.c:437 [inline] > ____kasan_kmalloc mm/kasan/common.c:516 [inline] > __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525 > kasan_kmalloc include/linux/kasan.h:234 [inline] > __kmalloc+0x138/0x257 mm/slub.c:4429 > kmalloc include/linux/slab.h:605 [inline] > ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline] > create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295 > create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline] > ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 > ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 > ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 > ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 > vfs_ioctl fs/ioctl.c:51 [inline] > __do_sys_ioctl fs/ioctl.c:870 [inline] > __se_sys_ioctl fs/ioctl.c:856 [inline] > __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0x0 > > The buggy address belongs to the object at ffff88802bb36e00 > which belongs to the cache kmalloc-256 of size 256 > The buggy address is located 0 bytes to the right of > 256-byte region [ffff88802bb36e00, ffff88802bb36f00) > > The buggy address belongs to the physical page: > page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000 > index:0x0 pfn:0x2bb36 > head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0 > flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) > raw: 000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40 > raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > ffff88802bb36e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffff88802bb36e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > ffff88802bb36f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ^ > ffff88802bb36f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ffff88802bb37000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ================================================================== > > Fixes: 801c135ce73d ("UBI: Unsorted Block Images") > Reported-by: syzkaller <syzkaller@googlegroups.com> > Signed-off-by: George Kennedy <george.kennedy@oracle.com> > --- > drivers/mtd/ubi/build.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c > index a32050fecabf..53aa4de6b963 100644 > --- a/drivers/mtd/ubi/build.c > +++ b/drivers/mtd/ubi/build.c > @@ -663,6 +663,12 @@ static int io_init(struct ubi_device *ubi, int max_beb_per1024) > ubi->ec_hdr_alsize = ALIGN(UBI_EC_HDR_SIZE, ubi->hdrs_min_io_size); > ubi->vid_hdr_alsize = ALIGN(UBI_VID_HDR_SIZE, ubi->hdrs_min_io_size); > + if (ubi->vid_hdr_offset && ((ubi->vid_hdr_offset + UBI_VID_HDR_SIZE) > > + ubi->vid_hdr_alsize)) { > + ubi_err(ubi, "VID header offset %d too large.", ubi->vid_hdr_offset); > + return -EINVAL; > + } > + This patch is in mainline as 1b42b1a36fc946f0d7088425b90d491b4257ca3e, and backported to various stable releases. For me this breaks ubiattach -m 0 -O 2048 I think the check ubi->vid_hdr_offset + UBI_VID_HDR_SIZE > ubi->vid_hdr_alsize is wrong. Without -O passed to ubiattach (and dynamic debug enabled) I get: [ 5294.936762] UBI DBG gen (pid 9619): sizeof(struct ubi_ainf_peb) 56 [ 5294.936769] UBI DBG gen (pid 9619): sizeof(struct ubi_wl_entry) 32 [ 5294.936774] UBI DBG gen (pid 9619): min_io_size 2048 [ 5294.936779] UBI DBG gen (pid 9619): max_write_size 2048 [ 5294.936783] UBI DBG gen (pid 9619): hdrs_min_io_size 512 [ 5294.936787] UBI DBG gen (pid 9619): ec_hdr_alsize 512 [ 5294.936791] UBI DBG gen (pid 9619): vid_hdr_alsize 512 [ 5294.936796] UBI DBG gen (pid 9619): vid_hdr_offset 512 [ 5294.936800] UBI DBG gen (pid 9619): vid_hdr_aloffset 512 [ 5294.936804] UBI DBG gen (pid 9619): vid_hdr_shift 0 [ 5294.936808] UBI DBG gen (pid 9619): leb_start 2048 [ 5294.936812] UBI DBG gen (pid 9619): max_erroneous 409 So the check would only pass for vid_hdr_offset <= 512 - UBI_VID_HDR_SIZE; note that even specifying the default value 512 (i.e. ubiattach -m 0 -O 512 ) fails the check. A less strong check would be: But I'm unsure if this would be too lax?! Best regards Uwe
Comments
Uwe, ----- Ursprüngliche Mail ----- > Von: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> > This patch is in mainline as 1b42b1a36fc946f0d7088425b90d491b4257ca3e, > and backported to various stable releases. > > For me this breaks > > ubiattach -m 0 -O 2048 > > I think the check > > ubi->vid_hdr_offset + UBI_VID_HDR_SIZE > ubi->vid_hdr_alsize > > is wrong. Without -O passed to ubiattach (and dynamic debug enabled) I > get: > > [ 5294.936762] UBI DBG gen (pid 9619): sizeof(struct ubi_ainf_peb) 56 > [ 5294.936769] UBI DBG gen (pid 9619): sizeof(struct ubi_wl_entry) 32 > [ 5294.936774] UBI DBG gen (pid 9619): min_io_size 2048 > [ 5294.936779] UBI DBG gen (pid 9619): max_write_size 2048 > [ 5294.936783] UBI DBG gen (pid 9619): hdrs_min_io_size 512 > [ 5294.936787] UBI DBG gen (pid 9619): ec_hdr_alsize 512 > [ 5294.936791] UBI DBG gen (pid 9619): vid_hdr_alsize 512 > [ 5294.936796] UBI DBG gen (pid 9619): vid_hdr_offset 512 > [ 5294.936800] UBI DBG gen (pid 9619): vid_hdr_aloffset 512 > [ 5294.936804] UBI DBG gen (pid 9619): vid_hdr_shift 0 > [ 5294.936808] UBI DBG gen (pid 9619): leb_start 2048 > [ 5294.936812] UBI DBG gen (pid 9619): max_erroneous 409 > > So the check would only pass for vid_hdr_offset <= 512 - > UBI_VID_HDR_SIZE; note that even specifying the default value 512 (i.e. > > ubiattach -m 0 -O 512 > > ) fails the check. > > A less strong check would be: > > diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c > index 0904eb40c95f..69c28a862430 100644 > --- a/drivers/mtd/ubi/build.c > +++ b/drivers/mtd/ubi/build.c > @@ -666,8 +666,8 @@ static int io_init(struct ubi_device *ubi, int > max_beb_per1024) > ubi->ec_hdr_alsize = ALIGN(UBI_EC_HDR_SIZE, ubi->hdrs_min_io_size); > ubi->vid_hdr_alsize = ALIGN(UBI_VID_HDR_SIZE, ubi->hdrs_min_io_size); > > - if (ubi->vid_hdr_offset && ((ubi->vid_hdr_offset + UBI_VID_HDR_SIZE) > > - ubi->vid_hdr_alsize)) { > + if (ubi->vid_hdr_offset && > + ubi->vid_hdr_offset + UBI_VID_HDR_SIZE > ubi->peb_size) { > ubi_err(ubi, "VID header offset %d too large.", ubi->vid_hdr_offset); > return -EINVAL; > } > > But I'm unsure if this would be too lax?! As written on IRC, 1e020e1b96af ("ubi: Fix failure attaching when vid_hdr offset equals to (sub)page size") is supposed to fix that and on it's way into stable. Thanks, //richard
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 0904eb40c95f..69c28a862430 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -666,8 +666,8 @@ static int io_init(struct ubi_device *ubi, int max_beb_per1024) ubi->ec_hdr_alsize = ALIGN(UBI_EC_HDR_SIZE, ubi->hdrs_min_io_size); ubi->vid_hdr_alsize = ALIGN(UBI_VID_HDR_SIZE, ubi->hdrs_min_io_size); - if (ubi->vid_hdr_offset && ((ubi->vid_hdr_offset + UBI_VID_HDR_SIZE) > - ubi->vid_hdr_alsize)) { + if (ubi->vid_hdr_offset && + ubi->vid_hdr_offset + UBI_VID_HDR_SIZE > ubi->peb_size) { ubi_err(ubi, "VID header offset %d too large.", ubi->vid_hdr_offset); return -EINVAL; }