From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f173.google.com (mail-dy1-f173.google.com [74.125.82.173]) (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 CC06D28751B for ; Sun, 14 Jun 2026 20:57:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781470624; cv=none; b=sXkXRtd9h6SY+LkRjd6MkEjUPXoQiuwZM6GHtFIZx9NP4EIL+gg4xrRmmGeVoXgC4yeOUOKVLE4unY8r3yOWMlCWNyqh7Cmwy/wCFr7L6QqX1oXd+yX/gbYHaIG/pS8Po7sy5vl1hyDEr0rk6WUi69DISst6sMZL80aTONh5u14= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781470624; c=relaxed/simple; bh=+bi8XwCzuwIhibsEF8K9s8nePKLZJJ3bOGbQ9AVgJ6Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ANcILgGP5sTLerSNl/2qk73RLjdv/3JQZyQPZOC9YsYaEhcWEiE+0AjHas/91fItlZWq4IdOyVI+I8oknx2P9BF2u79j02j1H0u9A4/NAoimrtT2hw9tlW2O6Fa4sYiDYtiF5/KAjOWmKLZnYzJAWBDIpKdpBXacui0NfYJCqGc= 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=KXUpFcjI; arc=none smtp.client-ip=74.125.82.173 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="KXUpFcjI" Received: by mail-dy1-f173.google.com with SMTP id 5a478bee46e88-3075ce9c05aso6634394eec.1 for ; Sun, 14 Jun 2026 13:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781470623; x=1782075423; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=a5fQgJl/JNDh0rlg6/DBaSueHDvPwrSzOEw4D/yzM6I=; b=KXUpFcjIZ/jFy0425QBnBgdBgC3zqCK10Hox0xjnGKe84qPAKziR/oJ5tzw68tUFsM 416x9o6SgNax1G+zGYRML9D6Gz3JqHdGN0wUmSdeVn0aTsBGoT84c0do8+DQ9IKT72Nr zl58flh/utdLPeT6OQreduj+xALdweBtXKZpk/OnUz2Tc7065Znlrs+eiPyPpiYx52ON IkC5p5D/9C7Jfcs78kU+ZjpHUR8Y1BKSpaACkZ4vAzZr9ERPZO6w3qo1Qy7aUMK9CjXg OhINfCUFgpbO1W6rNvNUYi5X5owIG46YQ63lKMaO6oiTj3I/AKEqQ0Qp7aRXkSFNWl8S qvFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781470623; x=1782075423; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=a5fQgJl/JNDh0rlg6/DBaSueHDvPwrSzOEw4D/yzM6I=; b=b2IiRWAzA7KOe7/ZdUcIugpbUqasufgIlhlXvl2VABcoKwUL02BTOY8Os6UMT8dyIM UG+oDwo47zycQ2V8BIQX9tQHkpni4IPAUDWoFlzZ5BqZpK3h8rjHmtME8+dFKu7BNIso rcKg1vsRLee/eamJRrxcKOESjqY1k5wUXKBDJGKkp+Gz4slMmr/bMnSZnLqIrHN+qGSl TeOAOPZNPCOhklMs4RtgnhKdxQVaeOXkeHQGSXj/IEicUDpKmZhDPCPoZ1gbEL3xZmXy 9A3eDgOpXNBUFs7b6BGHlp1QcpmeMkdLuQdizRGoTan5jY4EHJLbczv4GPcKXKmcxUr6 2UKg== X-Forwarded-Encrypted: i=1; AFNElJ9X5BjsMBG9yPLv3rmHb1u1Z6F/1SnRCdhuMFmYFZeoha8O2d/p6G9T4Vt8nkVNfKIytzKBg/fmJJuMlg0=@vger.kernel.org X-Gm-Message-State: AOJu0YxzyEJcxPPs3pwQVkQgeyOQgv5GCBo72SyLGGlfVTd34y2MrUGe 9i9zTFsP1GzS/DaMfCvSD2uzv5/6k+rY/H4E0Ph+FsafD4r1NtcyG9e5 X-Gm-Gg: Acq92OGcyQTaWB+/+d0PeGGJoVE7HZbThEMuex3wA0pJkQbus8I65wuzd9Q7hzYfa58 X1e9qi2myz/bmWe2a7GYe9UwSubvVBkWESw7nQtWXWP9I2ncgNahHEpcmlvbA56cO4L6G5gKXKI cCX99HWj2tZiXNW4FiJe8b/DmW+RERsKaBPLb5xlBFnlnK5Lvbdv/gehPUKEQiuV53b+ngYNWmz jvqGw+vvHTf+ptRSj89QGtwUEtCLH1Ae+XcjpcqGKnOaym7lvPlVpriEohaFnbm0GijRLqqI6XM eMpZ8R+87qkr+LL1dY21x4QJU9GXw6UvYpvrlDVQalPDfV2eU0pHzYH/Dti4I9N1pUy+w9bOHZF Jlf5RsFUrIqvM+KMvyoyF5SByPxePCetYHMvyu54EVMXPPYH5fFmfFQF4trwtrj1iJnflfQ02rT 7O8otT5waV71ZMvd3DbiKOWXKo47EPdcScnWO10h45V8kM0Zxio9VOMvYhlcvxZexZ X-Received: by 2002:a05:7300:7fa2:b0:304:6448:dfea with SMTP id 5a478bee46e88-308200de778mr7033067eec.33.1781470622807; Sun, 14 Jun 2026 13:57:02 -0700 (PDT) Received: from google.com ([2a00:79e0:2ebe:8:5d91:5c26:602d:6a99]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3081e489536sm12233295eec.2.2026.06.14.13.57.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jun 2026 13:57:02 -0700 (PDT) Date: Sun, 14 Jun 2026 13:56:58 -0700 From: Dmitry Torokhov To: hexlabsecurity@proton.me Cc: Sasha Finkelstein , linux-kernel@vger.kernel.org, Janne Grunau , linux-arm-kernel@lists.infradead.org, linux-input@vger.kernel.org, Sven Peter , asahi@lists.linux.dev, Neal Gompa Subject: Re: [PATCH v2] Input: apple_z2 - bound the device-reported finger count Message-ID: References: <20260613-b4-disp-4ebcbd68-v2-1-0161acfbd688@proton.me> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260613-b4-disp-4ebcbd68-v2-1-0161acfbd688@proton.me> Hi Bryam, On Sat, Jun 13, 2026 at 08:22:51PM -0500, Bryam Vargas via B4 Relay wrote: > From: Bryam Vargas > > apple_z2_parse_touches() takes the finger count from the touch > controller's report and loops over that many fixed-size finger records > without ever checking the count against the length of the report: > > nfingers = msg[APPLE_Z2_NUM_FINGERS_OFFSET]; > fingers = (struct apple_z2_finger *)(msg + APPLE_Z2_FINGERS_OFFSET); > for (i = 0; i < nfingers; i++) > /* read fingers[i] ... */ > > msg points into the fixed 4000-byte z2->rx_buf and nfingers is a single > device-supplied byte, so it can be as large as 255. A malicious, > malfunctioning or counterfeit controller (or an interposer on the SPI > bus) can report a large finger count in a short packet, making the loop > read up to 255 * sizeof(struct apple_z2_finger) bytes starting 24 bytes > into msg -- far past the 4000-byte buffer. This is a controller-driven > heap out-of-bounds read, and the finger fields that are read (position, > pressure, touch and tool dimensions) are forwarded to userspace as input > events, leaking adjacent kernel memory. > > Bound the device-reported count to the number of finger records the > report actually carries. As Sashiko mentioned, if we do not trust hardware to send valid data we should also validate that packet size supplied by the device is reasonable. Also I wonder why would we want to report some of fingers in case when device sends bogus number of contacts? I'd drop such packet (maybe logging ratelimited or "once" message). You can ignore Sahiko's comment about __free(kfree) not handling error pointers. Thanks. -- Dmitry