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 9026A343896 for ; Mon, 22 Jun 2026 18:18:26 +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=1782152307; cv=none; b=e8J7AyHoo1tiYq532adavWxRgDjC4lBlrQpdHT08WXWyXfxRvD/Hhz1QnAU8JKZXx27cRxUKuuKO5jzSJXmso+pDdmRzq0s28jPONfIPkm+orrxn8kcUNG7VyScm1k2RVAmwVDkhjuJjavB2DUHNe1uzI2nRM5lHP2x/LYOOSAc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782152307; c=relaxed/simple; bh=BPs0E0Sg6JSePXrntU9OMcGGkos5S/qvj3HCBcV4X7Y=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=hIEpw++3vBb1pUVrOLi6gVBItk/1tUSzuRpbWHZIsrcJxHtX3vP6k6aZiKdqjk7uSh6meIcIWSRXQ3TUPawa2eJ4UfnLPbpRWnM1mDg1v7arocY3OTg4AaE8TwHXpgj378O/HPhCR0fqQ8HK4qeH3uxZ/8npGstoo8T3ySeKviQ= 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=TD53GlfJ; 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="TD53GlfJ" Received: by mail-dy1-f173.google.com with SMTP id 5a478bee46e88-30c52cc5285so743544eec.1 for ; Mon, 22 Jun 2026 11:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782152306; x=1782757106; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=8UVsKCK9kHa09INWL8qmL+CtZFk3R2BbfKJt8UkBDd4=; b=TD53GlfJXNQrbigVFEhwBvEkYKlxBUSicqZ9kNsYrEGy10ELYPKboOlhoB9GxevsXB v371mFBVez4m2lP3AFmC/WnF41GMe1P0doQ062fUIUP+lTF9ylYroXnOlYxPsGOn2Hwn 8h4LKcwmBYopmARtpCYeGoUrwr3LVi7kiKr3HXFbTBwGcfIF7VrscB9e4IhVuSb37qDU Rdg7v1vV2zzu2dL/erFAGJUg9HAWS7AO6ODrY6QmigJbNPCNXrZ1UlARbNF3HNkx2HeT 28zEDme0Q9QKJpU/o3cU7epWMl96/UGUQpamM3ge4iVUoj4rM2VmIjpi3bjXLuiBp2ZE beeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782152306; x=1782757106; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8UVsKCK9kHa09INWL8qmL+CtZFk3R2BbfKJt8UkBDd4=; b=oVG6i/D9p/UScOjAbe3I17E39H73D8U/wbjZlW6OKIKZBWqJ/jf9E9WjR+/5O67upP QrQ8PwoCOaDEhdNmQeLkFSNs1zHt+XB27Rn8c0/C4cqMs4iS3TJ8HIOrbB+lMOr/L9V3 VTjVoZMohcvCjiKxMmWSG7YcrxkMcbIXUR5gt36AvO67W6oeaNX3fciWWWZqaxBa8Kuo kbkTOzuymSoBGQz7DkZlsOhp79FUVZCIIFVU0mMl7LH1Pe9DRfpqisUxqKE+2Y/QGKCd MjGHJ3jVp6R2P/RZU9Myrf9h10o3J1+So02Z+tEWnUY/bAXaX2xjWgoCNjRT4VbrsQjC ZN3Q== X-Forwarded-Encrypted: i=1; AHgh+RqjqG+YrDLGjW+6DdAtnWPCmvilVkvhF6rLLK1pNf0ODuqvtwGzzk5UgRGW0Wor5WI24bfz5PgoD8LUcg4=@vger.kernel.org X-Gm-Message-State: AOJu0YzMvogItF7rEkdrxUXgnkzUkmzp2TlQfxi/l+sCR1nAYclLiBQZ aCbf82DN6s/0v6T1ERbVTtKjnmpFeMD1tEr39hk6dTAcXqMUKxSxcNpH X-Gm-Gg: AfdE7ck+bvuRgty7ijwOxSbTxrZMT1Boq4wwmBrK24uerZNZDrT6xYYqY8OXGM+FQY/ q8dHFDNqzxYaD6VIV7hmU7SjyvsAUVnNzgDSYIFfnl0JfqjHqi5OmGtS/9blfd98NddYymuWBQj QSXXlYEkRQTYtVrson+19DGvBYnmBmqRoJLhNRmwlJNS9VnOBElzWFzzkvDlqgv3weHiTf03ame T9amWF6bGUEttNXo/GRrOVZRHd5CEZAQ3MkdMhViVT3tIZbGHbQ/Ps4/+qaDu722wPPO8HOFNBb OJ5QzhQvzPFSExyxOLtxHwWINdgmCkKiZFLCCrx0upZxoGcpbH8R+8NPpcItkzssNKhWvEQswox /v8hiBJhtzA2gItOHzm0ykYxqzOPPpYUZen9/6ikW9pzMCmbJ/yVVLt9YSngPcNZxcF84d/Mm7h 6iXGI1rOYNDhfFZgmTnQQ/HxnnHxOMmYuJ9jNG2XLAO+RAB/bt2zsRkIye2YvaW90jNiE= X-Received: by 2002:a05:7300:3c15:b0:304:ccdd:594a with SMTP id 5a478bee46e88-30c06d4bd52mr13258922eec.5.1782152305404; Mon, 22 Jun 2026 11:18:25 -0700 (PDT) Received: from ?IPv6:2a03:83e0:115c:1:6e2:c699:67c:63fe? ([2620:10d:c090:500::1:5387]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-30c1bd8d75csm10223340eec.15.2026.06.22.11.18.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jun 2026 11:18:25 -0700 (PDT) Message-ID: Subject: Re: [PATCH bpf-next v3 1/3] HID: bpf: Fix hid_bpf_get_data() range check From: Eduard Zingerman To: Yiyang Chen , Jiri Kosina , Benjamin Tissoires , bpf@vger.kernel.org, linux-input@vger.kernel.org Cc: Shuah Khan , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Kumar Kartikeya Dwivedi , Song Liu , Yonghong Song , Jiri Olsa , linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Date: Mon, 22 Jun 2026 11:18:22 -0700 In-Reply-To: <20260622073011.423657-1-chenyy23@mails.tsinghua.edu.cn> References: <20260622065246.414380-1-chenyy23@mails.tsinghua.edu.cn> <20260622073011.423657-1-chenyy23@mails.tsinghua.edu.cn> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.1 (3.60.1-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Mon, 2026-06-22 at 07:30 +0000, Yiyang Chen wrote: > hid_bpf_get_data() returns a pointer into the HID-BPF context data when > the caller-provided offset and size fit inside ctx->allocated_size. >=20 > The current check adds rdwr_buf_size and offset before comparing the > result against ctx->allocated_size. Since both values are unsigned, a > very large size can wrap the sum below ctx->allocated_size and make the > helper return a pointer even though the requested range is not contained > in the backing buffer. >=20 > Use a non-wrapping range check instead: reject offsets beyond the > allocation, then compare the requested size with the remaining bytes > after the offset. >=20 > Fixes: 658ee5a64fcf ("HID: bpf: allocate data memory for device_event BPF= programs") > Signed-off-by: Yiyang Chen > --- > drivers/hid/bpf/hid_bpf_dispatch.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >=20 > diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf= _dispatch.c > index d0130658091b0..09b45c40d84f0 100644 > --- a/drivers/hid/bpf/hid_bpf_dispatch.c > +++ b/drivers/hid/bpf/hid_bpf_dispatch.c > @@ -299,7 +299,8 @@ hid_bpf_get_data(struct hid_bpf_ctx *ctx, unsigned in= t offset, const size_t rdwr > =20 > ctx_kern =3D container_of(ctx, struct hid_bpf_ctx_kern, ctx); > =20 > - if (rdwr_buf_size + offset > ctx->allocated_size) > + if (offset > ctx->allocated_size || > + rdwr_buf_size > ctx->allocated_size - offset) Nit: imo, this is harder to read, I'd define a variable to hold the buffer end position, update it using check_add_overflow and then compare it against ctx->allocated_size, e.g.: if (check_add_overflow(rdwr_buf_size, offset, &end) || end > ctx->allocat= ed_size) ... pw-bot: cr > return NULL; > =20 > return ctx_kern->data + offset;