From: Jakub Kicinski <kuba@kernel.org>
To: Grzegorz Nitka <grzegorz.nitka@intel.com>
Cc: ivecera@redhat.com, vadim.fedorenko@linux.dev, jiri@resnulli.us,
edumazet@google.com,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>,
netdev@vger.kernel.org, richardcochran@gmail.com,
donald.hunter@gmail.com, linux-kernel@vger.kernel.org,
arkadiusz.kubalewski@intel.com, Prathosh.Satish@microchip.com,
andrew+netdev@lunn.ch, intel-wired-lan@lists.osuosl.org,
horms@kernel.org, przemyslaw.kitszel@intel.com,
anthony.l.nguyen@intel.com, pabeni@redhat.com,
davem@davemloft.net, Jiri Pirko <jiri@nvidia.com>
Subject: Re: [Intel-wired-lan] [PATCH v7 net-next 2/8] dpll: allow registering FW-identified pin with a different DPLL
Date: Sat, 2 May 2026 10:27:15 -0700 [thread overview]
Message-ID: <20260502102715.2ac364c8@kernel.org> (raw)
In-Reply-To: <20260430094238.987976-3-grzegorz.nitka@intel.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Grzegorz Nitka <grzegorz.nitka@intel.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, poros@redhat.com,
richardcochran@gmail.com, andrew+netdev@lunn.ch,
przemyslaw.kitszel@intel.com, anthony.l.nguyen@intel.com,
Prathosh.Satish@microchip.com, ivecera@redhat.com,
jiri@resnulli.us, 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>,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Subject: Re: [PATCH v7 net-next 2/8] dpll: allow registering FW-identified pin with a different DPLL
Date: Sat, 2 May 2026 10:27:15 -0700 [thread overview]
Message-ID: <20260502102715.2ac364c8@kernel.org> (raw)
In-Reply-To: <20260430094238.987976-3-grzegorz.nitka@intel.com>
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.
next prev parent reply other threads:[~2026-05-02 17:27 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 9:42 [Intel-wired-lan] [PATCH v7 net-next 0/8] dpll/ice: Add generic DPLL type and full TX reference clock control for E825 Grzegorz Nitka
2026-04-30 9:42 ` Grzegorz Nitka
2026-04-30 9:42 ` [Intel-wired-lan] [PATCH v7 net-next 1/8] dpll: add generic DPLL type Grzegorz Nitka
2026-04-30 9:42 ` Grzegorz Nitka
2026-04-30 11:49 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-04-30 11:49 ` Loktionov, Aleksandr
2026-05-05 7:43 ` Nitka, Grzegorz
2026-05-05 7:43 ` Nitka, Grzegorz
2026-04-30 9:42 ` [Intel-wired-lan] [PATCH v7 net-next 2/8] dpll: allow registering FW-identified pin with a different DPLL Grzegorz Nitka
2026-04-30 9:42 ` Grzegorz Nitka
2026-05-02 17:27 ` Jakub Kicinski [this message]
2026-05-02 17:27 ` Jakub Kicinski
2026-05-05 8:59 ` [Intel-wired-lan] " Nitka, Grzegorz
2026-05-05 8:59 ` Nitka, Grzegorz
2026-04-30 9:42 ` [Intel-wired-lan] [PATCH v7 net-next 3/8] dpll: extend pin notifier and netlink events with notification source ID Grzegorz Nitka
2026-04-30 9:42 ` Grzegorz Nitka
2026-05-02 17:29 ` [Intel-wired-lan] " Jakub Kicinski
2026-05-02 17:29 ` Jakub Kicinski
2026-05-02 17:31 ` [Intel-wired-lan] " Jakub Kicinski
2026-05-02 17:31 ` Jakub Kicinski
2026-04-30 9:42 ` [Intel-wired-lan] [PATCH v7 net-next 4/8] dpll: zl3073x: allow SyncE_Ref pin state change Grzegorz Nitka
2026-04-30 9:42 ` Grzegorz Nitka
2026-05-02 17:33 ` [Intel-wired-lan] " Jakub Kicinski
2026-05-02 17:33 ` Jakub Kicinski
2026-05-11 22:30 ` Nitka, Grzegorz
2026-05-11 22:30 ` [Intel-wired-lan] " Nitka, Grzegorz
2026-04-30 9:42 ` [Intel-wired-lan] [PATCH v7 net-next 5/8] ice: introduce TXC DPLL device and TX ref clock pin framework for E825 Grzegorz Nitka
2026-04-30 9:42 ` Grzegorz Nitka
2026-04-30 11:46 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-04-30 11:46 ` Loktionov, Aleksandr
2026-05-02 17:33 ` Jakub Kicinski
2026-05-02 17:33 ` Jakub Kicinski
2026-05-05 21:33 ` [Intel-wired-lan] " Nitka, Grzegorz
2026-05-05 21:33 ` Nitka, Grzegorz
2026-04-30 9:42 ` [Intel-wired-lan] [PATCH v7 net-next 6/8] ice: implement CPI support for E825C Grzegorz Nitka
2026-04-30 9:42 ` Grzegorz Nitka
2026-05-02 17:33 ` [Intel-wired-lan] " Jakub Kicinski
2026-05-02 17:33 ` Jakub Kicinski
2026-05-11 22:33 ` Nitka, Grzegorz
2026-05-11 22:33 ` [Intel-wired-lan] " Nitka, Grzegorz
2026-04-30 9:42 ` [Intel-wired-lan] [PATCH v7 net-next 7/8] ice: add Tx reference clock index handling to AN restart command Grzegorz Nitka
2026-04-30 9:42 ` Grzegorz Nitka
2026-04-30 11:29 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-04-30 11:29 ` Loktionov, Aleksandr
2026-04-30 9:42 ` [Intel-wired-lan] [PATCH v7 net-next 8/8] ice: implement E825 TX ref clock control and TXC hardware sync status Grzegorz Nitka
2026-04-30 9:42 ` Grzegorz Nitka
2026-04-30 11:33 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-04-30 11:33 ` Loktionov, Aleksandr
2026-04-30 11:37 ` Loktionov, Aleksandr
2026-04-30 11:37 ` Loktionov, Aleksandr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260502102715.2ac364c8@kernel.org \
--to=kuba@kernel.org \
--cc=Prathosh.Satish@microchip.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=arkadiusz.kubalewski@intel.com \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=grzegorz.nitka@intel.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=ivecera@redhat.com \
--cc=jiri@nvidia.com \
--cc=jiri@resnulli.us \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=richardcochran@gmail.com \
--cc=vadim.fedorenko@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.