From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 C1AC038657E for ; Wed, 29 Jul 2026 04:07:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785298039; cv=none; b=lySujfn2bZtyRMA9OLty2uru78W7xYpoG8+kAis8Bu1XD9ktNH6vgkAFc5pOZ9IbWWroH26pX+R7qcJGPmiYwSk7FAhMXUJPBkh8C6qYL6EIdEjCjcMNJU3t3GnkWY5PkskpM590P8mEjLP93uX+tuZlUHle74HOrFNLdDZCik0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785298039; c=relaxed/simple; bh=5u6ghBrhXGyP/MEBZFNvKYDEydau+rYuPskh4t7NgyA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=L7bTxtLK4oNHf4mqKjdJSROstPpLqGyOS+wrodcqlSmzTxCjG7iSsdqv8FDjY5zlnZv8AYIMGKunRgOWyITMk49WzAJNuFSgqiJsVfyOl3NgGLMVxGy52wzgRRmDGRQ6knYQWwweS3GQpG0oXBR0Ru02HIUBCyeoHI9yFLPqhDk= 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=pWGRGJ6G; arc=none smtp.client-ip=209.85.210.53 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="pWGRGJ6G" Received: by mail-ot1-f53.google.com with SMTP id 46e09a7af769-7e6b554044fso530660a34.0 for ; Tue, 28 Jul 2026 21:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785298036; x=1785902836; 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=nv0Upv1Vj3F4AGa3oq5CtafeDcw6cWVGiKmt6d8J7/4=; b=pWGRGJ6GPsnhVx3AxJOPSwRS/i4aF/j35IEIXcEBgqAc5il2qU8/KQkT/89abaJ3oj 2tE4PihxwcpYIolA2Q4r4H5AIKFtIxeC9l1k8QTUW6BbfiHFnWpX9Di/t0KWBs15oez0 9Mqm0d5tKKB1BR/W0ekTjXZ8lyp1i9HuAEC7g4gHNkrLzOtC2L+y9JiC+ftqFYwhsicC sj3PE3byP10Sc1e3CNdVUUykuVWtcWbZo8ts9/wuD/wnID9FQZeqB/xRmHlcQTQQNb30 mS06w4G2Hqddj4QFtFg9YODqyVMDBJ3xo0+0JnUSGjKVKEwwnXvRBp9T9ruMpjdvyLJg OiNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785298036; x=1785902836; 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=nv0Upv1Vj3F4AGa3oq5CtafeDcw6cWVGiKmt6d8J7/4=; b=TgCmdALoGDrJfKoZOB8eGMBm+NLqJ6zqWy/IWpfd4CdgAZWBuKQQMvIX8au0lrEnIK dHkVLa4kUTjrOQuH+BghmchYOrTLs0e1EED9wFvEK3MZ+Zn6ZjY3uWMGf1QzGhYjHGZ2 oc9lDCgEUfrGOxr1x4GiM/AcsC2V13VQm1WyNT1DqDmppgoJnN1u6kPAbOofMsdTHGLg SYAnJvopfC3JzlGnIg8ZIvGQyTkh9SjNASxxb1YFlFWwjTHR65rj+dB0B+gmwzgthiLp jN5UVVHkfysVD5hmTvn8AxQySM576zMcrzk1M0NjGp8w4wN4X8MkYcAA6RbiEV9F17Z9 9Abg== X-Forwarded-Encrypted: i=1; AHgh+RpCwuBf2kFm5pNuaV7Ja4iZINBL4t3NAqkDe/OOR3E0FvgN5E2Yvsu8alJuj8RxlL8cZ/yW++9ovsF7knY=@vger.kernel.org X-Gm-Message-State: AOJu0YykdLuvPrVY6CzX30S3Lb2eenrKJPegAmS1GqiWJCUsCwN76+vU BE6/QJqy8X0kgduRHn8AmvKu4mJHQ+VqPJMBSPJfc3IsRh/bEAplh7X4 X-Gm-Gg: AR+sD12NWLpncKYHPXWvDNX7MOXJdYbExCtktVFzEsbcMozIKGt+Uko2CNB1ytJst+A 54lRJtvSVM5HGxDAFNbKFVzV1LoL4+wSfALy7T+SvVlhLT2v6IEYBe0z4OBSQjXGJNXqatXaXQF DAF3+nBeKi364a+zKWNlNhPgTOlqUV/cq8E+K9Xr27KDhxYa0un0fLJMz7Iyvtk3A+5XrjvtKD1 XrjsMogsfrwCjQ3eRJdbx6xrIZqqRohU78W4BRhGUoZLHBZQE04MiO+UNhr3SAPXIuUrmMi7MTA prJU2PFsoLcMnWjrb5U9jyFwmznn943zQFhs5ah5LDLscXHEZjGAq6tvgFYT7JL/9qTUEG7wNWf 9Pp7FzSNOGpD69KtgtmiXi3IG3x/idWiZhhP/LBscob10FsDBjvXcMqJ0d3dwBZnqNn0WgCW7aV d/OivIhXCGGYinLWFdIjPjuvYaWNFdoXwAcOD2/4aEB2eG/u7GVdszLQudup80 X-Received: by 2002:a05:6830:6ad4:b0:7e9:e8a6:6389 with SMTP id 46e09a7af769-7effef00661mr3604326a34.4.1785298036531; Tue, 28 Jul 2026 21:07:16 -0700 (PDT) Received: from desktop ([2806:107e:1a:2f14:d204:ec3e:fc64:563b]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7f00d94d41csm1330516a34.24.2026.07.28.21.07.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jul 2026 21:07:15 -0700 (PDT) From: =?UTF-8?q?Jose=20Villase=C3=B1or=20Montfort?= To: Jiri Kosina , Benjamin Tissoires Cc: sashiko-bot@kernel.org, Alec Hall , 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: Tue, 28 Jul 2026 22:07:03 -0600 Message-ID: <20260729040703.1178791-1-pepemontfort@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260728185542.65F091F000E9@smtp.kernel.org> References: <20260728184059.688513-1-pepemontfort@gmail.com> <20260728185542.65F091F000E9@smtp.kernel.org> 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, sashiko-bot@kernel.org wrote: > [Severity: High] > This isn't a bug introduced by this patch, but does the !input check miss > dangling pointers if input_register_device() fails? It does, and I checked the path: this looks like a real bug, separate from the one this patch fixes. Thanks. hidinput_connect() unwinds through hidinput_disconnect() when input_register_device() fails, and that frees every input_dev it created -- including the one magicmouse_input_mapping() cached in msc->input. What makes it reachable is that the failure does not abort the probe. hid_connect() only skips the claim: if ((connect_mask & HID_CONNECT_HIDINPUT) && !hidinput_connect(hdev, connect_mask & HID_CONNECT_HIDINPUT_FORCE)) hdev->claimed |= HID_CLAIMED_INPUT; and the "device has no listeners" bailout right below does not fire for this driver, which sets ->raw_event (and on the USB paths hidraw/hiddev are claimed anyway). So hid_hw_start() returns 0, magicmouse_probe() carries on, and msc->input is non-NULL garbage: it passes the "input not registered" check in probe just as it passes the NULL guards this patch adds. The next report dereferences freed memory. The v1 of this patch, which rejected the bind in probe(), would not have covered it either, for the same reason. I will send a separate patch for it rather than fold it in here, since it is a different failure (use-after-free on an error path, not a NULL deref on a normal bind) and this one already has a Fixes: tag of its own. The fix I have in mind is to trust the core's claim rather than the cached pointer, i.e. clear msc->input in probe when the HID core did not claim an input device, so the existing NULL checks cover this case too. I am open to a different shape if reviewers prefer one. > [Severity: Critical] > This is a pre-existing issue, but does this function have an unbounded > recursion bug when processing a DOUBLE_REPORT_ID? Yes, and that one is already fixed in a patch on the list, with Reviewed-by and Tested-by from Alec Hall: https://lore.kernel.org/linux-input/20260715053526.574725-1-pepemontfort@gmail.com/ It bounds the depth to two levels by rejecting a nested DOUBLE_REPORT_ID, since a double report never wraps another one. Jose