From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) (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 7ACD025D530 for ; Tue, 4 Aug 2026 02:50:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811842; cv=none; b=E0338pxwjIx5b9JGytrH8fu3ix0yN1pdSZXHir93+/1m2IiPj/1mP3jH2h8vArPu22u8/OoDX5XORL/7gIR7ilDTZnQzqYzoMBShQhBjN/uBSLITvQsnVy/zfioiSaLSZeLKa8fkcuSyGO7LQWf3YyCQNRYAZgSfemFvdMYOVac= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811842; c=relaxed/simple; bh=HutMG7KAG/Bx9Rj8ElbrqT/jkccEafBBRKmOViSfxKI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=GaTB4JvygZS4d10c9rehvoP62iCzOSO/rz58/AwElTUrO7rf/wHJFTyk+ZTq6QlFzTceJNsB7WSX6/SwYugEzng/f0eajL/idWQCVlSpRG0sWHzayCd5xfGyVqrZpSaFTPgtvPUUN0h3gKHZekQfiTO8GaESgreDiNZ+C754boY= 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=NDaIAgjw; arc=none smtp.client-ip=209.85.210.50 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="NDaIAgjw" Received: by mail-ot1-f50.google.com with SMTP id 46e09a7af769-7ee4399c3abso3033210a34.2 for ; Mon, 03 Aug 2026 19:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785811839; x=1786416639; 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=Ek3HDMGwTzbO92vhRJd9hGiEBc7MF6sqhREDMAAlYbk=; b=NDaIAgjwopjiH4+Cbnun4g4Lwlm/AU5k/DrzNdue/i2EsOtQJlhLBaR2drAjqVq5UC 9wwadZ2wBi/xCRYzKtTfuLduRV9xsmxxWZbiR2xel9b+cgQCQUmp14kgbVFDBdmcu06Z Ow9mnZYanK2C5opUxo2hJVDvdw4tvoAXYCz/WCfevwV7ii5XSJxj2RDZTXdcRdcwA0AZ O+6Ut9XD6HhOBbS0IRiPrFuROdWC1WL9y2hgaJ7dBKezdvxu+0tQgHbl1GiqohcMBszu HahSbyRy8BNDE15TyX85AT2ei/cg4kVfcp7d0j0RTtHuR6qztLp+jLZ1pYp6DxhI6WZj r9wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785811839; x=1786416639; 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=Ek3HDMGwTzbO92vhRJd9hGiEBc7MF6sqhREDMAAlYbk=; b=Wnbk9kLWkfglA+7JGNdsGgmlcgtp3xC1M7cUTNui98aBikyT/31jEakxkD6rLjIePP NAmszOPI43MZ6N4uJoaGVlvDFVAl6Ot9ssfryG2lBzQAc5OfWTyq5idvfddB91LDypT/ PZGaW7zGL42C5Y6O8Mxge88e+yIirRzJfVvtphy9+uI3SB/PmP1JOw1kg4rWvbr/9KVh 3TGPendJo4TSCFW34a48Px7/rHBJMC/GK+O1TqcMTEUchUaka2ZaPp3+0q1e7wNv9puS wT6wmeA/0vK/9FvVJYjiexF3P4p6VDPRvgH3h6R/uueGpekwlUK8X/ef0SXP6TyDy5XE KfeQ== X-Forwarded-Encrypted: i=1; AHgh+RqywK2ZkYOJzABEuG5lf7FEhoY6Puqe8mBD0gT7p7+c4flP1kAtUPWAMfAQhS7Tz0BeqmVALZLyVWxef34=@vger.kernel.org X-Gm-Message-State: AOJu0Yw5MGsdVHVRbzuWXWdX1M+ieUZSdP3/KEqaDzkTNw/YKRdpMs81 tAklQm/uVrNzuCy73yBzUmaOu8FrSNj//Y2BuIxKXi9tFtH7koKk0ToKdcnkKSyk X-Gm-Gg: AR+sD10SfdrG6Po3uk9pTwMcSiNhZDLV8DfFjdYOowwRh32NlTQO/z5kYrKeSSmoeOX CzVio8n9t/T6sROGQcO8d2gRDANMRdA+LMrDwnYwcThah/OdFVeFK/T0o1p7OnYO6G1gQ8mznGa LJYzozQMR0Lz0NOunG29ctXbcc8j92cJOOK1fGn3/rMl+SECWXnBPkT7ZPajWSe4fiehUKC3OSD NCk25F5twGgpTueMcIuuwTr0/PuhCFbfB7cxnsIqA0sVqmVoBG7WrHHw4DzIGV0JmBa2Y1Ffpwu w5L+D1zDRrNDnIESIogBU/tXIBhZCWrSUi0w1G4mbu5J4wI+lnCenP/qJQ6E0F4b9sd+qc2exNE AxSW9PEe9+A6mfXMRbamO3JDI7G9rgjKgXm9up0IBN3pDwJI6/e9fFLUFs5C9GvA1EptRkF1+jl zmYhxen4MHcx9DqSFjssu7rKsPLCzqKhQk8Lx/uwQA+iUXjtSloIm3wqFcQoUl X-Received: by 2002:a05:6830:6a8d:b0:7eb:d848:c867 with SMTP id 46e09a7af769-7f196be5f52mr20079979a34.6.1785811839172; Mon, 03 Aug 2026 19:50:39 -0700 (PDT) Received: from desktop ([2806:2f0:9260:f072:92d3:78b1:9863:130a]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7f18ed3e3d5sm8516343a34.3.2026.08.03.19.50.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Aug 2026 19:50:37 -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 v2] HID: magicmouse: avoid NULL pointer deref when there is no input device Date: Mon, 3 Aug 2026 20:50:05 -0600 Message-ID: <20260804025005.2389635-1-pepemontfort@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260803033711.17170-1-signshop.alec@gmail.com> References: <20260728184059.688513-1-pepemontfort@gmail.com> <20260803033711.17170-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 Sun, Aug 02, 2026, Alec Hall wrote: > 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. No apology needed -- you got to it faster than I did. Thank you for the three reviews, and particularly for the fault injection on the stale pointer one: reproducing that state at all took more effort than the patch did, and being explicit about what it does not show (a real input_register_device() failure, and no KASAN) is exactly the caveat I would have wanted stated. > 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. Good, that is the behaviour the v1 broke and the whole point of the respin. Thanks for checking the Magic Keyboard on the same host too. Jiri, this one now carries Reviewed-by: Alec Hall Tested-by: Alec Hall from the message I am replying to. I mention it because you have already applied its sibling, "HID: magicmouse: do not keep a stale msc->input if no input is claimed", and the two are a pair: that one deliberately sets msc->input to NULL when the core claimed no input, on the basis that the NULL checks in ->raw_event and ->event -- which this patch adds -- make NULL the safe state. Applied on its own it turns a dangling pointer into a NULL one, which is an improvement but not the whole fix. That is also the answer to the Sashiko review of the stale patch [1], which asked whether clearing msc->input could leave a NULL dereference reachable through the early return on the USB Magic Mouse 2 / Magic Trackpad 2 path. It can, but that is not something the stale patch introduces: as Alec's dmesg above shows, the input-less vendor interfaces of a healthy trackpad have always reached ->raw_event and ->event with msc->input == NULL. Closing that is what this patch is for. > a device with a 16-bit or bit-packed capacity would read garbage > silently. A guard that falls back rather than mis-reading might be > worth it. Agreed, and thanks for spelling out that it is not a regression. The byte-aligned assumption is a real limit of what went in. Worth flagging here, because it is exactly that and has had no replies since it was posted: Mason Camara sent a series on Jul 12 that records the field offset and size and reads the value with hid_field_extract(), so a bit-packed or non-byte-aligned capacity is handled, and it comes with a UHID selftest: https://lore.kernel.org/linux-input/20260712044702.893825-1-ping@masoncamara.com/ To be straight about where I stand on it: I only found it after sending my v2, I have read it but have not built or tested it, and I have not written in that thread yet. On a read it is the more general of the two fixes. I will follow up with Mason there rather than prolong this thread. [1] https://lore.kernel.org/linux-input/20260729043135.9D4A51F000E9@smtp.kernel.org/ Thanks, Jose