From nobody Mon Feb 9 14:02:09 2026 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (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 AC5D733B6E5 for ; Wed, 14 Jan 2026 18:56:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768416999; cv=none; b=Vt+/ToG9bLyt33bi7j8zpPc9Kvkc2rL+Iu2m4yd+iYpficMisfsOcphX2u9WTt+2fkJ4VvzCVvGaAifYogQ8YMGtiazmPY2gg+cHlU/3Kar/6sbucPx5iFqvB5F+elTK7BTWwSgHnbrH8+22PqK7d3HXlsXLj/qoEC3r3kLkNrg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768416999; c=relaxed/simple; bh=AXNRP/RiCLJMNVTwYZ+/Hft1GlmSrxHJXn1qJl+YDzc=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=T8f+Mw0ob3S/5C5vDqS5UmEm9+GvLYojn9dNukrg25F9ftKPpdhHTZuYTjRQgP2GkkvUfZJyl+JAmgCdnd1wM2HQtOEnqrsIecbxRDjBPeXiYqlZRjlTwz79QJqCHI06HrHGI3Qe1cBk+yMn1dklkwawGvAMPJWKwsWqIrzeUm4= 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=K0lfE1gr; arc=none smtp.client-ip=209.85.160.172 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="K0lfE1gr" Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-5014453a0faso1107131cf.1 for ; Wed, 14 Jan 2026 10:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768416994; x=1769021794; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=A+EJOC7qOLDFLrRbX7fAQVQMiijpYhyrD0fxa6sn0aY=; b=K0lfE1grPY1UaIxPAWorwlITX3piRqRRS/DYaEXIqJptNdEyOAvqCIpCKOlIxlQhkq oH7Fj9LjDnx54QnFuCJZLRnsZ+FWw7GZINAKzt6WvZZt58h+6aTYG7hPlOXnNv/OE7fo 3IqxPuMWtpbQP4grJTxJd0JTolBs/dj2n0opRhhQ9MqwBUSVJP5r5Wsb5kXkamf4fR26 zuwHybRYLsVhVBPPEGfvO52KtUBUtgPHBwjM/OoiUvJrQ/NQ3C6SPhqYDnsP4KGFmteh uKHpSeITgVQwPiqJE7WX0wSrxJbtAgrpxBwX5H5WXaJRVK1nBldQmjsQhzPrMk/ymjaa jQdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768416994; x=1769021794; h=cc:to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=A+EJOC7qOLDFLrRbX7fAQVQMiijpYhyrD0fxa6sn0aY=; b=fd52tYuEQudKNclo0k8YyduNqj5GtMN60HynbIoEjkSy5twgX7E4YfJ2wWN/YYbTVb rwvtipTb6iHNMJP2dAeahp+1BnH2XviixwHni6a3naXPwiW7cqLSIdoiaZc5G8efELrj R6P5X5rAfLddDraLTzd8O0xP8lDXlv6ojV97gwrtPzmjVS8uwUs6arFLN1uKg2S1e7Nk /iFyxuJy2XiByfpIkr6Ztz+bkwBQNYPydTkLd+AfrMzyyHqX+D6ZAGZFv+415T+E18jY SSwlspczNT80mMtgJ/5yS5guOdqmrrYaX1+9u773u0SBclhIkABzt4g0qK5wSXfK+xd6 fPzg== X-Forwarded-Encrypted: i=1; AJvYcCXkXLJ8XF0YBN8VwvJEG8vvmYeh0i9HPro78wSGXSWfhNbLNNqejDoZqOoyEAi9OUBgRyZrOAus8Yd1cgs=@vger.kernel.org X-Gm-Message-State: AOJu0YwGE8keV0RBgcHtTPSE3BMlF7M3fw1B/af7qrLbohQ95kYUSNkq qt48xb3BQcqeOaVMgoqmvGgsdAP/kiV2WfdB+NWkBOiNRxB+kS93mPjcboyo2hqcVGRZFkAkn6q MCOMx4f601enuxWJoXIoKUosv/lGi8A== X-Gm-Gg: AY/fxX6qTGajwcgQQLSyYHNjxosSqNCM7AmrFlYg3X7ZK55ZiWZ+bcPXBb/y4PaXNUW hpX4QJkk3/GAIoh/hYMtQTMiHJTD+QYgn/PgdjqtkstBHdefq4GDZkr6I8tIlUKVaXEC7oLYDKZ SwOjtoeLE0O8l1naaoPiRyMj43OpDCGJnjelBbuphuximvUe7WcbxuR7TVM0nAMfqeagPR5Y2MZ BBVNS9GMp02tlQrewza8EpFpsAG/gmNnRmTV0InTgPVWNiltJw4hR/0fYOpIv4UV58FYQ== X-Received: by 2002:a05:622a:1981:b0:4ec:f23c:3b94 with SMTP id d75a77b69052e-50148220475mr53271891cf.36.1768416994344; Wed, 14 Jan 2026 10:56:34 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: =?UTF-8?B?6b2Q5p+v5a6H?= Date: Thu, 15 Jan 2026 02:56:24 +0800 X-Gm-Features: AZwV_Qj2YCYlu1ncELKP034wY7oXetlTPNzkZZ9QDYItQVL8R85W3WnppNZ-LiU Message-ID: Subject: [PATCH] usb: typec: mux: fix NULL pointer dereference in {typec_switch,mux}_put To: heikki.krogerus@linux.intel.com, gregkh@linuxfoundation.org Cc: andersson@kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This fix was discovered through static code analysis. In typec_switch_put() and typec_mux_put(), the code directly dereferences sw_dev->dev.parent->driver->owner without checking if 'driver' is NULL. This can lead to a NULL pointer dereference kernel crash. [Call Chain Analysis] The vulnerable functions are called through the following paths: Acquisition path (fwnode_typec_switch_get): typec_port_register() [class.c] -> typec_switch_get() [typec_mux.h] -> fwnode_typec_switch_get() [mux.c] -> class_find_device() (gets device reference) -> try_module_get(sw_devs[i]->dev.parent->driver->owner) -> stores to sw->sw_devs[i] Release path (typec_switch_put): typec_release() [class.c] -> typec_switch_put() [mux.c] -> module_put(sw_dev->dev.parent->driver->owner) <- BUG! -> put_device(&sw_dev->dev) Registration path (typec_switch_register): I2C/Platform driver probe() -> typec_switch_register(dev, &sw_desc) [mux.c] -> sw_dev->dev.parent =3D parent (sets parent device) -> device_add(&sw_dev->dev) [Data Flow Analysis] The critical data flow is: sw_dev->dev.parent: - Set by typec_switch_register() from the 'parent' parameter - Typically an I2C or Platform device (e.g., &client->dev) sw_dev->dev.parent->driver: - Managed by kernel driver model (drivers/base/dd.c) - Set to driver pointer when driver binds (really_probe) - Set to NULL when driver unbinds (__device_release_driver) [Race Condition Scenario] The vulnerability can be triggered by the following race condition: Thread A (normal operation) Thread B (attacker/event) ---------------------------- ------------------------- T1: typec_port_register() T2: fwnode_typec_switch_get() T3: try_module_get(parent->driver->owner) T4: store sw_devs[i] ... T5: echo > unbind T6: device_driver_detach() T7: parent->driver =3D NULL T8: typec_switch_put(sw) T9: module_put(parent->driver->owner) -> NULL pointer dereference! [User-Triggerable Paths] Users can trigger this vulnerability through: 1. sysfs unbind interface (requires root): # echo "" > /sys/bus/i2c/drivers//unbind 2. Module unloading (requires root): # rmmod 3. USB Type-C hot-unplug (physical access): Physically removing the USB-C device or its parent device How to fix: Add NULL checks for both 'parent' and 'parent->driver' before calling module_put() in typec_switch_put() and typec_mux_put(). Fixes: 71793b579ba68 ("usb: typec: mux: Allow multiple mux_devs per mux") Signed-off-by: Kery Qi --- drivers/usb/typec/mux.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c index 182c902c42f6..6ed8bb999ee0 100644 --- a/drivers/usb/typec/mux.c +++ b/drivers/usb/typec/mux.c @@ -134,7 +134,8 @@ void typec_switch_put(struct typec_switch *sw) for (i =3D 0; i < sw->num_sw_devs; i++) { sw_dev =3D sw->sw_devs[i]; - module_put(sw_dev->dev.parent->driver->owner); + if (sw_dev->dev.parent && sw_dev->dev.parent->driver) + module_put(sw_dev->dev.parent->driver->owner); put_device(&sw_dev->dev); } kfree(sw); @@ -358,7 +359,8 @@ void typec_mux_put(struct typec_mux *mux) for (i =3D 0; i < mux->num_mux_devs; i++) { mux_dev =3D mux->mux_devs[i]; - module_put(mux_dev->dev.parent->driver->owner); + if (mux_dev->dev.parent && mux_dev->dev.parent->driver) + module_put(mux_dev->dev.parent->driver->owner); put_device(&mux_dev->dev); } kfree(mux); --=20 2.34.1