From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f41.google.com (mail-oo1-f41.google.com [209.85.161.41]) (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 1DF0C304BDC for ; Tue, 28 Jul 2026 18:40:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785264002; cv=none; b=l6Lx9+ad/9uNOMzFMwldvdheiifQWjp5L/b/18/Va4sNQL4egYeEhoah8H1mXYMIEyD6m86U4beJb04zDfwdPw6TsokcQl7+Yf0qzDnB7BHS7JQakTuq1pG0J/SuoRf28pTw+sTe33iYHh9mgdDcxUDy2dESTwHWghRT18B27Pc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785264002; c=relaxed/simple; bh=wmgqjAU8LGLuTBGTqgtzum73+chcg63x9G/qkZbkq50=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Z6xjKU5uhngpLtvKyEbHtLsd1unp3zngNYNhepzuWGpG1lTbEIEZNytDb20H645gS5bWJjCiiAXBlYn6tiicftOivFkWS1Y32KGwk6UuFmWebnx71cqVD/4C9e0hWXpY9WSFGmDKqAmdiAN8Q5dkjDJjeBEr9RBdW7eXMpurk88= 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=I+a8sfvA; arc=none smtp.client-ip=209.85.161.41 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="I+a8sfvA" Received: by mail-oo1-f41.google.com with SMTP id 006d021491bc7-6aae5eb0ee0so80415eaf.3 for ; Tue, 28 Jul 2026 11:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785264000; x=1785868800; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Xkf9XQPSfNEqYu/lK1cOdYxG0oWwY1T1NURcZl6XkKk=; b=I+a8sfvAJSC49dT8agF9dHd+aX069jzRgNcQXqlQeVU23Ce1cNYADLGFW6qK8AILeb tYhmlXxhhByAtYwIiv9kWXjlRUPGViXkzO/MYEl4jpBGZo50ceTLuKkRpdG+8cWfPlHm J16iHGmsUUnnT0T3GRkhKEaGvbVD0wVLpOPMFYcm7zgY0z6kDa/Zu/y4lU0L9to7Zpm1 gs4Xaw55oGuDv5vmH8bd8VSmkSaxnwRL6zerFHzfYuofz5ST8fLUfwR52nFYZTZTF4BF dVIgrITmJFmaQeXLrBUnnDeXwHBjP1QBnrxEc73marbmCFFOLkto22X6N4i4jIcapmVq 1TGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785264000; x=1785868800; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Xkf9XQPSfNEqYu/lK1cOdYxG0oWwY1T1NURcZl6XkKk=; b=UMy2TUSn8x8ccQdEWqiGqGrF/0Xsx15UfrbJjJiAJZqLqLzJULQvPVNXVYh7em5XBl eAHnHHXcnwacoJktUFysJ5YeCJ90P5LR22xEemGStTLEyR7VkR4+9QSvZBA7WngQRbpV guX7nQjYMXNPbklANh1oSiS0W6W2RudTIUjSd31VorIQeBeijoFg06S24L7WhMlD0t+5 SKVWRzr+E2NQWczdPpmQTnkrLerzv1cjhMtg3LS/JnhUU1cycI/6fxoaMShVccqSpbFi ChfhNm/J//DPx5Syq36PwlkyHnx+VMHiBMp2QeIFv9KievcK//D7MV3SaQ66fepKeBYA hDQg== X-Forwarded-Encrypted: i=1; AHgh+RqwCGtC7UbcvtGrqtQqsL+B8HQJ/q3Py7WZVhQ6HH7a6OGl2ChHtQGkwhVRw7EDzbEtG2uAmVZgB5yDb9U=@vger.kernel.org X-Gm-Message-State: AOJu0YxPUvJKCiS1BChldhBUKZWrufEL1LJyb3AtZDKM8RjMNKxE2eaA kufjZ4TW00Qplw+x0VgwRcOZu4j4sX+y4L7Mi47oo2fcE9z9P0bhxeNQ X-Gm-Gg: AR+sD12AxD8Pq18J9U52IOhAxI/a44aUs0ZOM853dQ1h4g9RDnH46UgjkqKPE8fZzzo q7nyEnTrPACmgFE+WM+u38VsaNKzdr87nQ5Mc7j/TDykhNmiZ2BhXO7k5LoOweUa2jwKtYTBNsu yeuXJorzFTjLqWkvwBiQPqVHJi0R2bK6O97etxtbZfUDaE8c9li4cibT48uAeY61R6cUA9YSl5F gbNTRZhBMSILOXObQPzP5sMz/c+3skbJJGxvjMSwDohOsrvifKIM6tiC7ld5pLMTrKcBXwpvzEn IcB3+pvO0BpSLNSXTcSafsytkxrJ+sgvJ3uykueZQBCH+ieueDTt3FpHVny09TlVcW6+taANQ96 lekG9jPsN9PTl5kmZqUBxMk3auf9vWq2IIcQArL1R8jpUuIEgMOL1ifnwGv3nTkBgZWCBKJ6/mM GIZA== X-Received: by 2002:a05:6820:4b8d:b0:6aa:fc2b:eb04 with SMTP id 006d021491bc7-6ac96c4160emr1775325eaf.50.1785263999873; Tue, 28 Jul 2026 11:39:59 -0700 (PDT) Received: from desktop ([2806:107e:1a:2f14:d204:ec3e:fc64:563b]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7f00d8d397asm381363a34.17.2026.07.28.11.39.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jul 2026 11:39:59 -0700 (PDT) From: =?UTF-8?q?Jose=20Villase=C3=B1or=20Montfort?= To: Alec Hall Cc: Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, =?UTF-8?q?Jose=20Villase=C3=B1or=20Montfort?= Subject: Re: [PATCH] HID: magicmouse: reject devices that bind without an input device Date: Tue, 28 Jul 2026 12:37:46 -0600 Message-ID: <20260728183746.685507-1-pepemontfort@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260728072554.47069-1-signshop.alec@gmail.com> References: <20260715195853.1302765-1-pepemontfort@gmail.com> <20260728072554.47069-1-signshop.alec@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=UTF-8 Content-Transfer-Encoding: 8bit On Tue, Jul 28, 2026, Alec Hall wrote: > The second half of that turns out not to hold on real hardware. A USB > Magic Trackpad 2 exposes four HID interfaces, and only the first two > register an input; interfaces 2 and 3 are vendor-defined, hiddev/hidraw > only. Thanks for putting it on hardware. You're right, and the stable argument settles it -- unbinding two interfaces of a healthy device is not something to ship as a fix. v1 is dropped. I can confirm the same shape on the other model. A USB-C Magic Trackpad (05ac:0324) on an unpatched 7.1.5 here exposes three HID interfaces rather than four, all three bound to magicmouse: 0003:05AC:0324.0006 input=input12 hidraw=hidraw5 0003:05AC:0324.0007 input=input13 hidraw=hidraw6 0003:05AC:0324.0008 input= hidraw=hidraw7 Interface 2 is the vendor-defined one (bInterfaceSubClass 0, bInterfaceProtocol 0, two endpoints) and has no input device. So the interface count varies by model, but an input-less interface bound to this driver is plain normal. One thing worth adding to the picture: those interfaces do not merely bind with msc->input == NULL, they can also reach the dereference. hid_process_event() calls ->event without checking HID_CLAIMED_INPUT: if (hdrv && hdrv->event && hid_match_usage(hid, usage)) { ret = hdrv->event(hid, field, usage, value); ... } if (hid->claimed & HID_CLAIMED_INPUT) hidinput_hid_event(hid, field, usage, value); and hid_match_usage() returns 1 for everything here, since magicmouse declares no usage_table. So an input report on interface 2 or 3 walks into magicmouse_event(), which dereferences msc->input->id.product right at the top; ->raw_event is called for every report regardless. The NULL deref is therefore reachable on genuine hardware, not only on a device spoofing an Apple VID/PID -- a better justification than the one I sent, so thanks for that as well. v2 with the per-callback guards follows shortly. Both callbacks return 0, so those reports keep flowing through the generic HID paths exactly as they do today, and magicmouse_probe() is left alone. I've credited the change of approach to you with Suggested-by. The offer to re-test over USB and Bluetooth is very welcome, thank you. Jose