From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.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 3D3C544F54F for ; Sun, 11 Oct 2026 13:15:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791724526; cv=none; b=JUY8xPx0Uv4ajFq3wi6QPNYPfKTXVo6g0gh1bYy+7w//qsRoYgDoTBsUPC+ZiPNV/t1EsTZ4ynKW8iC1LiNoQQGfEJth54KF0u2MWsPladzCcYTQLnGd4fceAUw6AlkBnpYasdk6+kdtkM66Rd0d+S2sbvJSwkGu72GA46njC9M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791724526; c=relaxed/simple; bh=9B9X/gIi5DrIUQeFLc+juPsb6YF4O294TU63QHC/mw0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Zsrfky82DahjXgpoxlSw1yxhWZLcGPlGLsmMbYq78EJZxpTvmwGP8/iRx6PH+kS9B50UyPyeRErAnbeeeQ3WpWux4pee5itqJHViJ8WNjNM4vhAeBmSDYD4sS/52/nqb3lo53pT8RQgZ1gyocBOOi7PQ3MeD4pA91AEi9qf32eU= 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=P+qjTGbr; arc=none smtp.client-ip=209.85.208.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="P+qjTGbr" Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-6a0794669a6so1638859a12.2 for ; Sun, 11 Oct 2026 06:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791724523; x=1792329323; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=n6tSFeETOL0w0YG7EtJiKwNHh1JrtAxAwON5yzkpP6k=; b=P+qjTGbrEVSI9Z/xYVdhSc2Kkt6fxjlTjlSBBUtd5+0Mv6yQXzoeXRP0aB9p11/mNq LaQx0FmnZw4/NyUwrU9PqXkMLATPQC4iUnGiz2sSyVQSbWUTQR4wqkzWlLFLliEo8nBe bRAJmOTKKrHBkhlNcUxQ9hGU25aGC0r/Di1Ma8xUw0rzj0WVMiUiK0AQrs+cXnWzxswN ZXIPKHMml9i/oviTeAg8XbNzhfnAFVnqXvOvZ8vRcsemURSVfm4QsWGSyUCR+EQE85iX DhfK1c9216QYJM5xvyOwBAM5PubOAotmSoGnQiDxSF40FR8OMEAtJB2xeqLk4r9EXGyR JV/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791724523; x=1792329323; h=content-transfer-encoding:mime-version: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=n6tSFeETOL0w0YG7EtJiKwNHh1JrtAxAwON5yzkpP6k=; b=YF+MB8uhz6kNlyEa3+B9gC5rXkG0cptwUsOCDmq1pHfZb/t3oBzTFEAgOPmGEC//k8 OmQLkHzG7YO403wjuMPavV+mXlSOgiSejbVKyxT8CbRcv+xHb007cRvtoP48KlysJbqO 1ncxebYBEE6w3ubaS0yPyYXHkIuB+HC2AOWr2EYq+yoKu3R9cIrkOgNgik/AOLjvZKw+ lkaFbUWT4ZuMZ/mokNtLuwtDKaNCs6xiULnhe8h330iVjS9qQRpuj66+0NT7nJE3M61s vYoVngaE7iEmSNNmf5IfrjvrjZnt8Rl2CxV8xW+xVxcFlgeQo9HCXhIJEHD8aywjYFd0 UqZA== X-Forwarded-Encrypted: i=1; AKwUvByWENQQsEFIwFx0Qw8bbpHotxCfoTVFVxQWxqwVL4Z2HipLY+tnecN2zdN+GfgmfmgVtrnARpRghQN4Qg==@vger.kernel.org X-Gm-Message-State: AFq9FYI6xu1jN4wZEyFqpNLuB4N5sVkLtDc5K00VlRYlGaZho1WkPaJu ax2igNwLX+HwTMTZhiCcE+72N01F3dyvjWKMnn27iKwkmAg6YuneK4nz X-Gm-Gg: AYBFou1MLEw08VJKJiJcoglY4tMe7+1jGwV9QQxoWSXm9iEVE22G+X43bw6afda0XSu XbQgGgQrFCunroBg2efui3rQJT6a6DClyQzCJicq5wDPs4FHIxlU+zUXbT+gR/INCJQxdXKyabh zUdgysQVCHRZl0Xzg5K1VDM1RDv8qj2FZ0MIwkaZIF4TuKMonbIcZppfbSm7G+jJPzA3T/SQTfR fbrN9pcbdRfiLal4f29jzGkRAeAQxFycl+iN2cx/TMOO3MEiLaveOuQEzUGvY/JhkNJ1tkk/c5v tbfgZOpyZC1KZnpgdGMoXEk0ilXYRlvf8Y51bm1EiQBaubw2bzz7q0P1pV8TIIYN1989P5TbClX oW8KWdK7/jbpKkCjK12J1yA3lsFdqvfhBZ8aXETBq6NPqLfTIXB9HnKQu3SlY6DFksXXWNkzJMi m/W1LHUL9lr+GBAjX6tILa2nGOTV1uKUKcTXnrKGNnPK1tncCmtY6F0Qyfym7VyNOErupHXJ1Em UNHGW4OCCOaQWs= X-Received: by 2002:a05:6402:24a5:b0:6a7:ee55:dcc9 with SMTP id 4fb4d7f45d1cf-6b17c29d39dmr6011742a12.24.1791724523262; Sun, 11 Oct 2026 06:15:23 -0700 (PDT) Received: from pythagoras.home ([178.226.135.249]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6b1aaec1b9dsm1026665a12.0.2026.10.11.06.15.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 11 Oct 2026 06:15:22 -0700 (PDT) From: Eduardo Ruiz Duarte To: sakari.ailus@linux.intel.com, bingbu.cao@intel.com, djrscally@gmail.com Cc: andriy.shevchenko@linux.intel.com, heikki.krogerus@linux.intel.com, tian.shu.qiu@intel.com, lixu.zhang@intel.com, linux-media@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Eduardo Ruiz Duarte Subject: [PATCH] media: ipu-bridge: hold a reference on the IVSC software node Date: Sun, 11 Oct 2026 15:15:18 +0200 Message-ID: <20261011131518.48838-1-toorandom@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ipu_bridge_instantiate_ivsc() attaches the IVSC software node to the mei-csi device with set_secondary_fwnode(), but never takes a reference on it, while the driver core unconditionally drops one when that device goes away. device_add() calls software_node_notify(), which does a kobject_get() on the swnode behind dev_fwnode(dev). device_del() calls software_node_notify_remove(), which does the matching kobject_put() -- and that put sits *outside* the "if (swnode->managed)" block, so it runs for every device whose fwnode is a software node, managed or not: sysfs_remove_link(&swnode->kobj, dev_name(dev)); sysfs_remove_link(&dev->kobj, "software_node"); kobject_put(&swnode->kobj); if (swnode->managed) { set_secondary_fwnode(dev, NULL); kobject_put(&swnode->kobj); } csi_dev is the mei-csi device, which the MEI client bus has already added by the time ipu_bridge_instantiate_ivsc() runs. The add-side get therefore never happens for this node, but the del-side put always does. On hardware where the MEI bus resets -- which it does on every s2idle and S4 resume on a Dell XPS 13 9340 -- mei-csi is destroyed and recreated each cycle, so the node loses one reference per resume. INTC10CF-N starts at 3: one for its own registration plus one for each of its two port children, since kobject_add() of a child takes a reference on the parent. The third resume therefore frees it, software_node_find_by_name() starts returning NULL, and isys walks the fwnode graph into freed memory: refcount_t: addition on 0; use-after-free WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x7e/0xb0 kobject_get+0x94/0xb0 software_node_graph_get_port_parent+0x89/0xd0 fwnode_graph_get_port_parent+0x70/0xd0 fwnode_graph_get_endpoint_by_id+0x93/0x280 isys_notifier_init+0x92/0x180 [intel_ipu6_isys] isys_register_devices+0x3c9/0x4e0 [intel_ipu6_isys] isys_probe+0x3df/0x500 [intel_ipu6_isys] auxiliary_bus_probe+0x4c/0x70 ... deferred_probe_work_func+0xa5/0x110 followed by an underflow and a saturate on the same kobject, and the camera never comes back. Take a reference so the attachment owns one, balancing the put the core will do when csi_dev is destroyed. Where csi_dev is never destroyed this leaks a single kobject reference, which is what the lifetime of the node already assumes. Found while making the camera survive hibernation on a Dell XPS 13 9340 (ov02c10 behind an INTC10CF IVSC); with suspend-then-hibernate the first cycle burns two resumes, so the failure consistently showed up on the second hibernation. Tested on 7.0.0-1015-oem: two consecutive hibernations with the node alive throughout and no refcount warnings, where before the second one hung the machine. Signed-off-by: Eduardo Ruiz Duarte --- drivers/media/pci/intel/ipu-bridge.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/drivers/media/pci/intel/ipu-bridge.c +++ b/drivers/media/pci/intel/ipu-bridge.c @@ -765,6 +765,15 @@ if (!fwnode) return -ENODEV; + /* + * Balance the kobject_put() that software_node_notify_remove() will do + * on this node when csi_dev is destroyed. That put is unconditional, + * while the matching get in software_node_notify() only happens at + * device_add() time -- and csi_dev was added before we got here, so it + * never ran for this node. + */ + fwnode_handle_get(fwnode); + set_secondary_fwnode(sensor->csi_dev, fwnode); return 0; -- 2.51.0