From nobody Thu Apr 9 04:04:23 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6BCD4334C33 for ; Wed, 11 Mar 2026 07:47:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773215272; cv=none; b=Qpb3ygG2j4AaJX4yg+z7A2FhjukzACGn+IHP2VuHIfM258PpzIITJw4q5HA/eSuSGvZRfu5KA6OFolWSAqm5bOLQsclKxyMsFjSKsb5O/mmoTD4e3Wvzxwr3GMIswBP8AaivKuv81/eQbjHVnSYdi1X8A6N0NMN8CfUb+bFQ9CA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773215272; c=relaxed/simple; bh=VEGQFLlVWIxjhhmfPpYtmtzxtfLNy7thkPyoCewk3vo=; h=Date:From:To:Subject:Content-Type:MIME-Version:Message-ID; b=pTR1hSYRYLdKYdAHhTq0EPC0kNiEW2ggiRkSjx08YhCuWjoUYrwgMoxAkZKlL3SPG54DauSPEiIP6EJoZDmEb7K5zaSYoXH4EWOu+89KEEtL8H3wUWDNCxDjM/YK7NTFZEXuSGeFnmK6m/M6w5fjj3cnZUUPMBs3CvDwknpHLzU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=MggrhXuv; arc=none smtp.client-ip=220.197.31.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="MggrhXuv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:To:Subject:Content-Type:MIME-Version: Message-ID; bh=VEGQFLlVWIxjhhmfPpYtmtzxtfLNy7thkPyoCewk3vo=; b=M ggrhXuvyVaaJ02r6iidnWT588+YYTIlNTOm3NtuadRSnBVS+8HRZixqQbzznIJha ITw6nj6s20iQrKfUDdk5uCtflP8zhU/AwSPYb09b3y1JcANBPnUbUejkzDZm4ZHi 1ymfFX3L5oj7804y1ZsAn7Bbzgf6Sxg7ckNHLjGyz4= Received: from luckd0g$163.com ( [183.205.138.18] ) by ajax-webmail-wmsvr-40-127 (Coremail) ; Wed, 11 Mar 2026 15:47:30 +0800 (CST) Date: Wed, 11 Mar 2026 15:47:30 +0800 (CST) From: "Jianzhou Zhao" To: jack@suse.com, linux-kernel@vger.kernel.org Subject: KASAN: slab-out-of-bounds in udf_adinicb_writepages X-Priority: 3 X-Mailer: Coremail Webmail Server Version 2023.4-cmXT build 20251222(83accb85) Copyright (c) 2002-2026 www.mailtech.cn 163com X-NTES-SC: AL_Qu2cAf6aukou5iKRZ+kfmU4Rhug7UMO3uf8n24JfPJ9wjA/p2yseUUF9NmPf88CwFTuXvxiGfTNO1/ZAU5Bifrwxl8q3w2/soQU2J3qm0TwGFQ== Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: X-Coremail-Locale: zh_CN X-CM-TRANSID: fygvCgDnj40SHrFpTLx2AA--.38948W X-CM-SenderInfo: poxfyvkqj6il2tof0z/xtbC9hJS3GmxHhKmnwAA3H X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Content-Type: text/plain; charset="utf-8" Subject: [BUG] udf: KASAN: slab-out-of-bounds in udf_adinicb_writepages Dear Maintainers, We are writing to report a KASAN-detected slab-out-of-bounds vulnerability = in the Linux kernel within the UDF subsystem. This bug was found by our cus= tom fuzzing tool, RacePilot. The bug occurs because `udf_adinicb_writepages= ` blind-copies folio data up to `i_size_read(inode)` into a fixed-size `iin= fo->i_data` allocation, which is bound by the superblock blocksize minus th= e UDF file entry structure size. When a file grows beyond this capacity wit= hout being expanded out of its ICB, a buffer overflow takes place. We obser= ved this on the Linux kernel version 6.18.0-08691-g2061f18ad76e-dirty. Call Trace & Context =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BUG: KASAN: slab-out-of-bounds in memcpy_from_file_folio include/linux/high= mem.h:629 [inline] BUG: KASAN: slab-out-of-bounds in udf_adinicb_writepages fs/udf/inode.c:195= [inline] BUG: KASAN: slab-out-of-bounds in udf_writepages+0x380/0x470 fs/udf/inode.c= :211 Write of size 4096 at addr ffff88804e3a1400 by task kworker/u10:5/1152 CPU: 1 UID: 0 PID: 1152 Comm: kworker/u10:5 Not tainted 6.18.0-08691-g2061f= 18ad76e-dirty #43 PREEMPT(full)=20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/= 2014 Workqueue: writeback wb_workfn (flush-7:4) Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x5f0 mm/kasan/report.c:482 kasan_report+0xca/0x100 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:194 [inline] kasan_check_range+0x39/0x1c0 mm/kasan/generic.c:200 __asan_memcpy+0x3d/0x60 mm/kasan/shadow.c:106 memcpy_from_file_folio include/linux/highmem.h:629 [inline] udf_adinicb_writepages fs/udf/inode.c:195 [inline] udf_writepages+0x380/0x470 fs/udf/inode.c:211 do_writepages+0x242/0x5b0 mm/page-writeback.c:2608 __writeback_single_inode+0x127/0x12c0 fs/fs-writeback.c:1743 writeback_sb_inodes+0x71a/0x1b20 fs/fs-writeback.c:2049 __writeback_inodes_wb+0xbe/0x270 fs/fs-writeback.c:2129 wb_writeback+0x6dd/0xae0 fs/fs-writeback.c:2240 wb_check_start_all fs/fs-writeback.c:2365 [inline] wb_do_writeback fs/fs-writeback.c:2390 [inline] wb_workfn+0x87e/0xb80 fs/fs-writeback.c:2423 process_one_work+0x90e/0x1b10 kernel/workqueue.c:3262 process_scheduled_works kernel/workqueue.c:3345 [inline] worker_thread+0x67e/0xe90 kernel/workqueue.c:3426 kthread+0x3d0/0x780 kernel/kthread.c:463 ret_from_fork+0x966/0xaf0 arch/x86/kernel/process.c:161 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 Allocated by task 23775: kasan_save_stack+0x24/0x50 mm/kasan/common.c:56 kasan_save_track+0x14/0x30 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __do_kmalloc_node mm/slub.c:5652 [inline] __kmalloc_noprof+0x32c/0x940 mm/slub.c:5664 kmalloc_noprof include/linux/slab.h:961 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] udf_new_inode+0xab4/0xe60 fs/udf/ialloc.c:56 ... =20 The buggy address belongs to the object at ffff88804e3a1400 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 0 bytes inside of allocated 336-byte region [ffff88804e3a1400, ffff88804e3a1550) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Execution Flow & Code Context When a new UDF inode is created `udf_new_inode` allocates an internal `i_da= ta` slab cache tailored precisely to fit inline file information within a s= ingle logical block:=20 ```c // fs/udf/ialloc.c struct inode *udf_new_inode(struct inode *dir, umode_t mode) { ... iinfo->i_data =3D kzalloc(inode->i_sb->s_blocksize - sizeof(struct fileEntry), GFP_KERNEL); ... } ``` If the file operates in ICB (In-ICB data allocation), the file payload resi= des fully buffered in `iinfo->i_data`. During dirty page writeback, `udf_ad= inicb_writepages` iterates the data mapping copying directly from the page = folio into `iinfo->i_data`: ```c // fs/udf/inode.c static int udf_adinicb_writepages(struct address_space *mapping, struct writeback_control *wbc) { struct inode *inode =3D mapping->host; struct udf_inode_info *iinfo =3D UDF_I(inode); struct folio *folio =3D NULL; int error =3D 0; while ((folio =3D writeback_iter(mapping, wbc, folio, &error))) { BUG_ON(!folio_test_locked(folio)); BUG_ON(folio->index !=3D 0); memcpy_from_file_folio(iinfo->i_data + iinfo->i_lenEAttr, folio, 0, i_size_read(inode)); // <-- Out of bounds write folio_unlock(folio); } ... } ``` Root Cause Analysis A slab-out-of-bounds defect occurs because `udf_adinicb_writepages` trusts = `i_size_read(inode)` to determine the length parameter for the `memcpy`. Ho= wever, a malicious or fuzzed operation can stretch the generic `i_size` pas= t the maximum limit bound by the slab allocation limit (`inode->i_sb->s_blo= cksize - sizeof(struct fileEntry)`) without triggering `udf_expand_file_adi= nicb` logic appropriately. Because `memcpy_from_file_folio` writes into the= exact chunk boundary, anything exceeding the residual allocation capacity = writes straight over the adjacent kmalloc chunk redzones. Unfortunately, we were unable to generate a reproducer for this bug. Potential Impact This out-of-bounds write is severe as the overflowing buffer is fully exter= nally controlled from user-space data stored in the folio. This capability = enables targeted memory corruption into adjacent slab objects (e.g., inside= kmalloc-512 allocations), likely leading to Privilege Escalation or remote= code execution primitives, or at minimum triggering Denial-of-Service via = Kernel Panics. Proposed Fix A swift defensive measure is enforcing a capacity sanity limit constraint b= efore committing the memory copy inside `udf_adinicb_writepages()`. The max= imum allowed write length should be strictly bounded to `iinfo->i_lenAlloc`= or the underlying static allocation limit `inode->i_sb->s_blocksize - size= of(struct fileEntry)`. ```diff --- a/fs/udf/inode.c +++ b/fs/udf/inode.c @@ -188,12 +188,14 @@ static int udf_adinicb_writepages(struct address_spac= e *mapping, struct udf_inode_info *iinfo =3D UDF_I(inode); struct folio *folio =3D NULL; int error =3D 0; + size_t max_len; =20 while ((folio =3D writeback_iter(mapping, wbc, folio, &error))) { BUG_ON(!folio_test_locked(folio)); BUG_ON(folio->index !=3D 0); + max_len =3D min_t(size_t, i_size_read(inode), iinfo->i_lenAlloc); memcpy_from_file_folio(iinfo->i_data + iinfo->i_lenEAttr, folio, - 0, i_size_read(inode)); + 0, max_len); folio_unlock(folio); } ``` We would be highly honored if this could be of any help. Best regards, RacePilot Team