lkml.org 
[lkml]   [2026]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v7 net-next 2/8] dpll: allow registering FW-identified pin with a different DPLL
Date


> -----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

\
 
 \ /
  Last update: 2026-05-05 11:00    [W:0.111 / U:5.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog