From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (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 8E9F036494C for ; Mon, 3 Aug 2026 03:37:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785728279; cv=none; b=KJSfiLYe43R2IuIHH28PiwGHYpU61z2Gqjv8EH2NRN3fFuepRPhV5B27N7vfxkgBWZPecphxofR7H6gujja1Q2MXVhhbX0PuRFaU2wtyxt0DdPs1il++VZVtAIcWxTmhtePqODlIn4ItkdL+pXfKHmcHzrSNSEFwDTZo4hsOgk8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785728279; c=relaxed/simple; bh=3kJ62rXINY4asL6Hx9/+1kOA+4Koy+GW8WaWXMRufps=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=qBlNY/yYi8DNJSaDf9G2pF3uO97EXj1nMP1FFFCgZVx4j3nndFJMhjh0fokIxFrf4OZwWIbmjHJtobqXF/AWV8bQpFakj5aLNlK4kQ1MQMt3VsRq27Y+ehdbGN1hYZa5VbMrPTiGwhl0AWEhvwyeuyeUuwWaxtUnQtqVCKq25wc= 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=clw7VOMq; arc=none smtp.client-ip=209.85.219.46 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="clw7VOMq" Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-8f186025973so30064676d6.0 for ; Sun, 02 Aug 2026 20:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785728277; x=1786333077; 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=IWZjKROXd+TbmXeZiVJROjtuTyAG639iOHSKl662uNg=; b=clw7VOMqPu+TI6Wa61n/3VgIW3fBABm+UE6G7hAZKV1fj69aGblNGW0sIjXg9yYRbO VtWIpAB5EWXuhR2l+Ng7y1BRlgwq1dl5wmYrvJWJhFrzMnxflM8mAJprMWWor24CEbNU kKnummIJJ8GCot6nKaDWubt3iKfaOFtUDBr+yIE6yjw7+P09kYc31e5UFCR0XM051s6J bsNcq+aSkvhTBuKDYKqv7Am64j9527fgkiotS3Uq6IZX75AN4Psx6a+TLQgKNgQYZ/OS gb3PCmN8MaHiiWktfCldIrnfGLWDTARi0/NxsVV9EQNSD0AKHuSUXnyY4A0mSxt73xbD wmzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785728277; x=1786333077; 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=IWZjKROXd+TbmXeZiVJROjtuTyAG639iOHSKl662uNg=; b=cIvdDPXLz4BzSVWO76tRbvVX6txNB2XKY729eJF4LELDa0RQU1io64pVVVvPwgj1Ce nM5cMi0l4aPqSXHIRWYI/MaJAsmfGgafLR+gZaKPieuX9ZvWLBfTqe4vDMkTxI7xcKY0 7+JJpPRD2H518eNlb7exuOFdBB77W49uXjHgF40HnkLJsTvyyYxJGqyUavXkSo8iepPX x6TKqYeWiTKPpC8IfGwWScCJcKRYHwJl6fECJRJTGDwHiCc7ZQQkuY9pWoqt1fGFD7Ga 3pgJo426wcJXAWs7bQhatkZJ7JDnTh64pzP72HrDCOwYFXAGUAr3hpvCdcC7DLUZxioy z9cw== X-Forwarded-Encrypted: i=1; AHgh+RoxO/Q/GfXtJjYNSnzZGsrnUXlnNRcgovYWVS6Y5wlSkn8hBFx+RLXiiSr4v/DGeyZmK3qAERrZdbKUVbo=@vger.kernel.org X-Gm-Message-State: AOJu0Yz9vpELmUNZcMYanDiBYEzQWPR2vH9pKVOijX0MUFb3UOHDEnpj MSe3lbCTwIYN4gOLhezcSu/EEbq4N4631jovLnQazWiPyHwSrXUWMRTDcRBmdV/H X-Gm-Gg: AR+sD10yQrW3S8gb9QdvUCfyegRnOvcLweCX162vptzxJyPOvoogvgSJ9+7RsTkHAnB eJzIuc3Ml/JX+3AkJMKnhwb4wDwq1va42ny/Qm5UOwtLYkybAaowU0+I+l19/0vRBVKlg16pEef ORIJ/iE4QlMYDPK8+ZACXdqqLGc3LcIMnhLhDH3Skmwu8ljbLB47Nmz8IjtFbfmiXudUnj+MZwa qHeM8TcBpNUUBAb3TeyZE/2h83NLxgQpFdSKppxdFaM69/0HzXQJdIf3bkT3zqsZXvRCOq4YzgZ GTkKd75ASLTCg+uZRP0ouTCx2i5Ui/bdmQ2irEMeOBh3wLYCvuOX8YwXr58EualEhUMXVsoRg9z 5x1e0dw8uAeCVIX17JWAKoxXy+1cRXLRPxjQ1tdwF/fIf9APxFPsUAqkZhz/7Tc07twDA0j9U+6 YgekXU4oU1vlg4ZJEfQ6cBGq08oeGlAapsLzJK1Q0uMkpdIpTxZ8DQR4nf79aqnMVQMwhHKJ3bD Fb9Oe3WPA== X-Received: by 2002:a05:6214:5196:b0:8f7:3902:42b2 with SMTP id 6a1803df08f44-9084965c5f0mr176385206d6.27.1785728277443; Sun, 02 Aug 2026 20:37:57 -0700 (PDT) Received: from FairplayBox ([2601:5cf:837e:d920::f9a2]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-908435b609csm65419786d6.26.2026.08.02.20.37.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Aug 2026 20:37:57 -0700 (PDT) From: Alec Hall To: pepemontfort@gmail.com Cc: jikos@kernel.org, bentiss@kernel.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Alec Hall Subject: Re: [PATCH v2] HID: magicmouse: avoid NULL pointer deref when there is no input device Date: Sun, 2 Aug 2026 23:37:09 -0400 Message-ID: <20260803033711.17170-1-signshop.alec@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260728184059.688513-1-pepemontfort@gmail.com> References: <20260728184059.688513-1-pepemontfort@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, Jose Villaseñor Montfort wrote: > Bail out of both callbacks when msc->input is NULL and leave the report > to the generic HID paths, which is what those interfaces get today. > Rejecting the bind in magicmouse_probe() instead would unbind interfaces > that a healthy device legitimately exposes and drop their hidraw nodes. Apologies for the near-week delay in getting back to you -- I was away on an anniversary trip and without physical access to the test machine for part of it, which this needed. Sorry to have left you waiting. This is the right shape, and thanks for turning the v1 report around so quickly. Both callbacks return 0, so reports on the input-less interfaces keep flowing through the generic HID paths exactly as they do today, and nothing about which interfaces bind changes. Your ->event analysis holds up on a read of the code: hid_process_event() calls ->event before the HID_CLAIMED_INPUT test, and with no usage_table in this driver hid_match_usage() returns 1 for every usage, so the guard in magicmouse_event() is doing real work rather than being defensive. Tested on a Magic Trackpad 2 (05ac:0265) on 7.1.5, over both transports. My tree carries the DOUBLE_REPORT_ID recursion fix [1], so the raw_event guard went into __magicmouse_raw_event() -- the trivial rebase you described; it sits above the size check, as in your patch. Over USB all four HID interfaces bind to magicmouse and keep their nodes: 0003:05AC:0265.0014 input48 hiddev102,hidraw7 0003:05AC:0265.0015 input49 hiddev109,hidraw15 0003:05AC:0265.0016 hiddev110,hidraw16 0003:05AC:0265.0017 hiddev111,hidraw17 Interfaces 2 and 3 bind with msc->input == NULL, as they always have, and there are no probe failures in dmesg -- the two "magicmouse input not registered" lines per plug that v1 produced are gone. Pointer motion, multi-finger gestures and clicks are unchanged, and the battery reads 74% "Charging" while cabled. Over Bluetooth the trackpad reconnects and behaves the same, battery 74% "Discharging" after unplugging, and a Magic Keyboard on the same host is unaffected. No splats or call traces in dmesg on either transport. Reviewed-by: Alec Hall Tested-by: Alec Hall [1] https://lore.kernel.org/linux-input/20260715053526.574725-1-pepemontfort@gmail.com/