From nobody Fri Jun 12 11:07:37 2026 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3003C329E44 for ; Fri, 15 May 2026 13:05:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778850358; cv=none; b=cfzfOOGVIHEK2qv6TWq2fQirOL0Yr3egsz9GvgaGIvsVCt7vo3nVMnwafcjymQPSRKs7m55qiXIRMVcLXA+YCUiU5D994ddOpFiaDKNFw7bq3ivae5w8wg88XyIkqr2yKmPa2lkKq3O06fpgqjuQpo4nz4Sd1Mrnaz+wLT7XfRw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778850358; c=relaxed/simple; bh=iWY+q9sLtnNig3SzAMNoTAy7uLEwPsn7zXPcA9ddAwU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Z0y13ePbv4v9EIb6gQ3OjUY+wBkzQRB0I8gyNpExHIYBK7kPtDCst0odWbglUQHVJXZ3IodX3vdfdt0Cm1dJFbfc98TmlBn2CyYmPaXywTaPwF7pMoQ2/v7f4GqYvOL9AzHPrf7Er1gTettMvo9mw6p/XeyBcJl48oCvDCVZnTc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jPwPsFQb; arc=none smtp.client-ip=209.85.214.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jPwPsFQb" Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-2ba928852a5so61617685ad.1 for ; Fri, 15 May 2026 06:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778850354; x=1779455154; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=yQMFhBzx5aVGgtqoPDMmCR48uTyf1EP0ur/Np06OS/8=; b=jPwPsFQb+s6t2c0rKm1YZgMBc/bEsp3RGYvMYGe8g/c5DqXJsttt3TUDiYxYjk/jqC eWTV2cMJ8zj6xFtgNTHPTsv2zD69hALwTuhEAP/cFS+LG0J7katkLyuDfD3hG6QfQ3YS Bm6wsZvI4hDj8RcaYsO5iLCzTCNIWIifPzpPZfeCKE3qasRLYFpzrju4x9ADsVo97+7g vG2BA0hCVw1nbQHn5tmZmCdpZL0/IKPR9N4ElsVFteEGwo6wUPqsG1LeN9dU45nWWNxA kA5Sib1DuWoqYt6STaStgmF22krs9BO/jy9J8JVsSvCh1D0GD5HlJCTbdQB5UC0RD6yr w5Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778850354; x=1779455154; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yQMFhBzx5aVGgtqoPDMmCR48uTyf1EP0ur/Np06OS/8=; b=IIzc9ouL/7u0GL/67U9LM9VH4IO8M87S5C4NWdipzvWOcuANOUBcgd70tp15L1l6n1 UdNwh7BJYnweA94a58x+u9aQ5WTfTpY/YAjbd/t9eoKuhOaOvRtA2p7Vlga1UVwCZWjz ryZRnw4rElu2ZWTgV4wG4q4gPVOngJWdAMNayBLumsvEt8yexIZE6TjM1Jq/ZrUJfn+s ZGgTcav9gSdBbeI/btsIaFMTb8Ot1Ag3eTYU0/a5fPi/EBczK60URTfN4kAy+WOsSQRX ZDGkj4lN/IvlZ0CznQ6vR4tEGOMMbrGDKVstIQr27g6LDykOqLubeHbGfgTR/H05DW/Z 5wqw== X-Forwarded-Encrypted: i=1; AFNElJ/yYiHwM5sIUMTBFZnrncU6Ks307DfcU/sBJwtzCBF3IkGTI8Hm2/2rKSsx7UfwRU37cYRdJoI+NIsERRI=@vger.kernel.org X-Gm-Message-State: AOJu0YyJmPN3SPNvvHwa2SO/Dx/9E0OAZ8ocnpUSuvH5tOWVBhFDaO27 UGdhFZjYPRGBdKTj7qLdpRY6g8DVsH4ik+AgfhqyacPzTbpZ6nuhiuE= X-Gm-Gg: Acq92OHtelNjva7Kat/AnpQF3SwsICmW6IrW8i5PydXXDoK6m3t6DFB/uiRNnqCS3fq SfODMRKRpDEx/mBNr7n29pA1Jd91ybvUVSeVo4qq9gesGaqcrgC2kjmpH+UrUmI5o/E2q7JZl32 x0FISDusxX8THjQYkLvATyMXq49mujgT/NQw5MK3Z7gHLEuHYl5C/X8Je1MKariTZe4++/b83gG UpW19PhflSk+H0fooEnHC3zhSLAM5tlQLfHNnUfwPK9Z8M9Vxg+twvls/p4RPUVDj7TqJ3WA5hm cj88IBtWCKIRXdOdGdVae1q6XvWRajJ8w+RJCNAwJxKMoQkHfGtKqoPtJeLj6I8HKWLYndLL0VR wn8A+VVNnABblTvEb4yW3llI48dV27pm+1RtFm4cLRpZsK7/Avs/xwXfICD9qvrD+m45KBg8Fgp cQJl0WAas9Cif75ejqzJuj5vVhXMX00PJnVC5dziflMD/YR0Jsa9W2ik2pSAw= X-Received: by 2002:a17:903:b45:b0:2b9:cd2d:6f13 with SMTP id d9443c01a7336-2bd7e7d88e8mr49950205ad.10.1778850353958; Fri, 15 May 2026 06:05:53 -0700 (PDT) Received: from mi-ThinkStation-K.mioffice.cn ([43.224.245.228]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2bd5d0fbc05sm60630605ad.57.2026.05.15.06.05.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2026 06:05:53 -0700 (PDT) From: Xinhao Lv To: Wolfram Sang Cc: Xinhao Lv , Andi Shyti , linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller@googlegroups.com Subject: [PATCH v2] i2c: dev: cap msg length against allocated buffer in i2cdev_ioctl_rdwr Date: Fri, 15 May 2026 21:05:23 +0800 Message-ID: <20260515130545.991714-1-lvxinhao.dev@gmail.com> X-Mailer: git-send-email 2.50.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Xinhao Lv In i2cdev_ioctl_rdwr(), the buffer for each I2C message is allocated via memdup_user() using the user-supplied msgs[i].len. However, the underlying I2C adapter driver may modify msgs[i].len during i2c_transfer() (e.g., for I2C_M_RECV_LEN messages where the actual length is determined by the slave device). After i2c_transfer() returns, copy_to_user() uses the potentially modified msgs[i].len without verifying it still fits within the originally allocated buffer. If an adapter driver sets msgs[i].len to a value larger than the allocation, this results in an out-of-bounds read from the SLUB object, which CONFIG_HARDENED_USERCOPY detects as a kernel memory exposure attempt: usercopy: Kernel memory exposure attempt detected from SLUB object 'kmalloc-128' (offset 0, size 271)! Call trace: usercopy_abort+0xe0/0xe4 __check_heap_object+0xd0/0xf0 __check_object_size+0x398/0x4a0 i2cdev_ioctl_rdwr+0x298/0x3f0 i2cdev_ioctl+0x160/0x5a0 __arm64_sys_ioctl+0x114/0x170 Fix this by saving each message's original allocation length before calling i2c_transfer(), and capping msgs[i].len to that saved length before copy_to_user(). This ensures we never copy more bytes than were actually allocated, regardless of what the adapter driver does to the length field. Found by syzkaller on an ARM64 platform. Signed-off-by: Xinhao Lv --- v1 -> v2: resend with git-send-email to fix formatting (v1 was mangled by Outlook, leading whitespace in diff was stripped) drivers/i2c/i2c-dev.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c index ccaac5e..af5b0a7 100644 --- a/drivers/i2c/i2c-dev.c +++ b/drivers/i2c/i2c-dev.c @@ -244,6 +244,7 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_client= *client, unsigned nmsgs, struct i2c_msg *msgs) { u8 __user **data_ptrs; + u16 *orig_lens; int i, res; =20 /* Adapter must support I2C transfers */ @@ -254,6 +255,12 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_clien= t *client, if (!data_ptrs) return -ENOMEM; =20 + orig_lens =3D kmalloc_array(nmsgs, sizeof(u16), GFP_KERNEL); + if (!orig_lens) { + kfree(data_ptrs); + return -ENOMEM; + } + res =3D 0; for (i =3D 0; i < nmsgs; i++) { /* Limit the size of the message to a sane amount */ @@ -268,6 +275,7 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_client= *client, res =3D PTR_ERR(msgs[i].buf); break; } + orig_lens[i] =3D msgs[i].len; /* memdup_user allocates with GFP_KERNEL, so DMA is ok */ msgs[i].flags |=3D I2C_M_DMA_SAFE; =20 @@ -300,12 +308,15 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_clie= nt *client, for (j =3D 0; j < i; ++j) kfree(msgs[j].buf); kfree(data_ptrs); + kfree(orig_lens); return res; } =20 res =3D i2c_transfer(client->adapter, msgs, nmsgs); while (i-- > 0) { if (res >=3D 0 && (msgs[i].flags & I2C_M_RD)) { + if (msgs[i].len > orig_lens[i]) + msgs[i].len =3D orig_lens[i]; if (copy_to_user(data_ptrs[i], msgs[i].buf, msgs[i].len)) res =3D -EFAULT; @@ -313,6 +324,7 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_client= *client, kfree(msgs[i].buf); } kfree(data_ptrs); + kfree(orig_lens); return res; } =20 --=20 2.50.1