Messages in this thread |  | | From | "Nitka, Grzegorz" <> | | Subject | RE: [PATCH v7 net-next 2/8] dpll: allow registering FW-identified pin with a different DPLL | | Date | Tue, 5 May 2026 08:59:28 +0000 |
| |
> -----Original Message----- > From: Jakub Kicinski <kuba@kernel.org> > Sent: Saturday, May 2, 2026 7:27 PM > To: Nitka, Grzegorz <grzegorz.nitka@intel.com> > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; intel-wired- > lan@lists.osuosl.org; Oros, Petr <poros@redhat.com>; > richardcochran@gmail.com; andrew+netdev@lunn.ch; Kitszel, Przemyslaw > <przemyslaw.kitszel@intel.com>; Nguyen, Anthony L > <anthony.l.nguyen@intel.com>; Prathosh.Satish@microchip.com; Vecera, > Ivan <ivecera@redhat.com>; jiri@resnulli.us; Kubalewski, Arkadiusz > <arkadiusz.kubalewski@intel.com>; vadim.fedorenko@linux.dev; > donald.hunter@gmail.com; horms@kernel.org; pabeni@redhat.com; > davem@davemloft.net; edumazet@google.com; Jiri Pirko <jiri@nvidia.com>; > Loktionov, Aleksandr <aleksandr.loktionov@intel.com> > Subject: Re: [PATCH v7 net-next 2/8] dpll: allow registering FW-identified pin > with a different DPLL > > On Thu, 30 Apr 2026 11:42:32 +0200 Grzegorz Nitka wrote: > > Relax the (module, clock_id) equality requirement when registering a > > pin identified by firmware (pin->fwnode). Some platforms associate a > > FW-described pin with a DPLL instance that differs from the pin's > > (module, clock_id) tuple. For such pins, permit registration without > > requiring the strict match. Non-FW pins still require equality. > > AI asks what prevents the modules from disappearing: > > Does this relaxed check expose pin->module to a use-after-free during > netlink queries? > If module A registers a firmware-described pin allocated by module B, > they will have different module pointers. > Because fwnode_dpll_pin_find() increases the pin's refcount but does > not take a reference to module B via try_module_get(), it appears module B > could be unloaded while module A still holds an active reference to the pin. > When module B unloads, its struct module memory is freed, leaving > pin->module as a dangling pointer. > A subsequent user-space Netlink query using DPLL_CMD_PIN_GET iterates > over > the registered pins and calls nla_put_string() with module_name(pin- > >module), > which would dereference the freed module memory.
This AI review comment is a valid concern. I'm going, of course, to address it in the next iteration.
Thanks
Grzegorz
|  |