From mboxrd@z Thu Jan 1 00:00:00 1970 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 D692148380C for ; Fri, 24 Jul 2026 23:48:48 +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=1784936932; cv=none; b=jLCF6jjdg7KJnhLiXsPiCJKbPpZE06KfAUm7+7gBbmEQwH6v2pa9xI5/JsBmuXbdOsln1xzyoumZYwWeezZEsuTQURnN8tiuovoy+UCP7W2zVu5fgzTIPyrRUwzf4nZl4UalbDrujqGYFQ1Rid5BFOoQP6I4MXuWZeL9sEJbrE4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784936932; c=relaxed/simple; bh=5gdN6MbyupG4up2v3CNyc/2HhdKCpR12n0Nqn1/8SxM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PEcp6j+gj8rS/LLeU1rpbJ2Njx9Q9chrnhSGhzeuVETlF5zzdPk1O5WX5vR0zBvSInbtCnBCyzMoZ9wLC5O/NEwoALDLbFhPUdWVxCr/5d7q2Vh4KVAgtWIoyfnXabBY284A9dLRL7YZbK0GYUmf1E0+/UB/cV3ASCIZcYEtOgI= 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=iycXByNc; 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="iycXByNc" Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-2ceaf8a1265so12669725ad.2 for ; Fri, 24 Jul 2026 16:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784936924; x=1785541724; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=isHJkq5dJt9QVOk/Tc0QQ/ea7BPXsGmxmAavDSM2GtA=; b=iycXByNcCkV+Lca+jVCFyK2Rxx9DID1p4PNmB35s0uSRQswHqN6XbbKeN0hETemWf0 wSFQ6NFYiande5nAMPgz8W1bf75o+NmWKSWhGxFNVo4lUqI53qzZWpXC49ERee+/IJis 8LMdg0c0ZgTdLBn6xt/mG4MOZXqXpwSIeDje73Hybvpa+KG63IOWwrpUYHVdiGRTpAes ag/KoCW0DGdzsg/CDE5GSmgl0a35wvAlN8JLRCgsasiMHlmQyBPlxS1xPX1dwPtOlvCY 1BsU2TGhjEY7tJZVvVC/I1SlGRUnkkG68o3vX/aTFoDRxTSh7GQBty9k9Lsy+dBa4V4V 9s/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784936924; x=1785541724; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=isHJkq5dJt9QVOk/Tc0QQ/ea7BPXsGmxmAavDSM2GtA=; b=SQFBXKgOy2sneLDl5cC/s0WDSYHHObxXz9XCJb+6yedcGVGinjDo6r7V+1wNBWpG2u hIbhVRIJRTq6IPrypThy59fEKxzEt+7u4c6mFlXNZOph6JOyURr1fm8niuWdeSA+GGv4 X1HBlZ7tslsWwtOfiH8fYXhgvaW/Gant0pi4OOmqUpYVD3gBUOEA7XexmIfC2Cv9WNJo 4eryp7jsRLc/xEx0XHhwijKtDdwqzZlzbc51M/5CzwSxWolgkY1FYFG9/XyQ9jiER4BQ 7oOd9bOhNQvMY2d4J64MInQaEj8TO3DlXeMBmDMSIoM2CHNPA6o5og59Ju931fxLbEYb fwQw== X-Forwarded-Encrypted: i=1; AHgh+RpVJXl26MRqyuhKCqK5Jct7qIWYD9K4j33cyug/Bpqdu2OJgde2vx3Iv3hfawooAX7BMGMBg4puMmg9dQo=@vger.kernel.org X-Gm-Message-State: AOJu0YzayiY9BwGeWNYKgIVV8WYwsYbnkUBm4u07G2jYuTsJaYR89G4f U8i3j7oR7tvC8FWs4fSMbDMUO2rNGXvQRMgdpOYjL/py1ykEHjDwzNba X-Gm-Gg: AR+sD13mBC6UL8Daa894Dw+puBoqxtjkS2e1+cTwdX4EiSnIqtqw/rSt2XslaMr6WMW VcnMi59o3L1pN3OyTLKpuCguZxt4PE6zo+O6ql2AYIrID/s/ph574ntv0Gw+hDeCZJbtLTZYr7H cTLMegmwGZh6jU+GBfzvhlt3jdtDhLlTCxuBK8edvzYIR+NfhXOBfOsZ1ZEdELSsckaAMWCCYFx cHFZW8Xu6/11nzRm7H2CAZjpVlW0mMGCQctwZdM6jFtyOmo4KxOQ+81IuF9imYoUFfASPslrvfX 2dPrfzEb8yr3Zro/6rvSuYpDnQW3u4MRyjRe5XCJWezlTy6nsKNcYcA05Qx2iDvT2sg/TBFDZ0t PN0qpzcY3eQHZ1TvPxVnUa56lxyKH9fhREjCpJjlwdEvwtauqyLTcMytNlYw/8I5DTGl/wrecme X810eMlQOcvrvP0ydck/mev1UyvvXUQgN9AiXqVQ813dtCL2IbXrlWrw== X-Received: by 2002:a17:903:46cc:b0:2c6:9f66:d573 with SMTP id d9443c01a7336-2cfde67beebmr4779085ad.2.1784936924553; Fri, 24 Jul 2026 16:48:44 -0700 (PDT) Received: from google.com ([2a00:79e0:2ebe:8:40e1:40e4:dabe:543e]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-314bc548f5dsm3900707eec.17.2026.07.24.16.48.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jul 2026 16:48:43 -0700 (PDT) Date: Fri, 24 Jul 2026 16:48:40 -0700 From: Dmitry Torokhov To: HyeongJun An Cc: James Ogletree , Fred Treven , Ben Bright , patches@opensource.cirrus.com, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] Input: cs40l50-vibra - validate custom data from user space Message-ID: References: <20260718074032.1864861-1-sammiee5311@gmail.com> 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: <20260718074032.1864861-1-sammiee5311@gmail.com> On Sat, Jul 18, 2026 at 04:40:32PM +0900, HyeongJun An wrote: > cs40l50_add() copies the custom data of an FF_PERIODIC/FF_CUSTOM effect > straight from the ff_effect the user passed to EVIOCSFF, without > requiring it to hold anything: > > work_data.custom_data = memdup_array_user(periodic->custom_data, > periodic->custom_len, > sizeof(s16)); > work_data.custom_len = periodic->custom_len; > > The driver then reads two words out of that buffer: custom_data[0] as the > waveform bank in cs40l50_effect_bank_set(), and custom_data[1] as the > index within the bank in cs40l50_effect_index_set(). Neither read is > covered by a length check, and custom_len is fully user controlled: > > - custom_len == 0 makes memdup_array_user() call memdup_user() with a > length of zero, which returns ZERO_SIZE_PTR rather than an error, so > custom_data[0] dereferences it. > > - custom_len == 1 allocates two bytes. A bank of ROM or RAM keeps > effect->type out of the OWT case, and custom_data[1] is then read one > word past the allocation. > > The bank value itself is also mishandled. It is masked with > CS40L50_CUSTOM_DATA_MASK (0xffff) but stored in an s16, so a > custom_data[0] of 0x8000 or above wraps to a negative value that passes > the "bank_type >= CS40L50_WVFRM_BANK_NUM" test. > cs40l50_effect_index_set() indexes vib->dsp.banks[] with it before the > switch statement's default case gets a chance to reject it: > > base_index = vib->dsp.banks[effect->type].base_index; > max_index = vib->dsp.banks[effect->type].max_index; > > Require the two words the driver reads to be present, and hold the masked > bank in a u32 so the existing upper-bound test covers the whole range. > The da7280 haptic driver already range checks custom_len this way. > > Fixes: c38fe1bb5d21 ("Input: cs40l50 - Add support for the CS40L50 haptic driver") > Cc: stable@vger.kernel.org > Assisted-by: Claude:claude-opus-4-8 > Signed-off-by: HyeongJun An Applied, thank you. -- Dmitry