dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()

[PATCH net] dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()

Posted by Ivan Vecera 2 weeks, 1 day ago

When a dpll_pin is shared across multiple dpll_device instances and
those devices are being unregistered (e.g. during driver module removal),
a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync().

This happens under the following conditions:
 - A pin is registered with two or more dpll devices (dpll_A, dpll_B)
 - The pin has ref_sync pairs with other pins
 - During unregistration of dpll_A's pins, a ref_sync partner pin is
   unregistered first, removing it from dpll_A->pin_refs
 - But since the partner pin is still registered with dpll_B, its
   dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT
   run and the partner stays in the pin's ref_sync_pins xarray
 - When the pin itself is then unregistered from dpll_A, the delete
   notification calls dpll_msg_add_pin_ref_sync() which finds the
   partner in ref_sync_pins, passes dpll_pin_available() (partner is
   still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A,
   partner) returns NULL because partner was already removed from
   dpll_A->pin_refs
 - The NULL priv pointer is passed to the driver's ref_sync_get
   callback, which dereferences it

 BUG: kernel NULL pointer dereference, address: 0000000000000034
 Oops: Oops: 0000 [#1] SMP NOPTI
 RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x]
 Call Trace:
  dpll_msg_add_pin_ref_sync+0xb8/0x200
  dpll_cmd_pin_get_one+0x3b6/0x4b0
  dpll_pin_event_send+0x72/0x140
  __dpll_pin_unregister+0x5a/0x2b0
  dpll_pin_unregister+0x49/0x70

Fix this by skipping ref_sync pins whose priv pointer cannot be resolved
for the current dpll device.

Fixes: 58256a26bfb3 ("dpll: add reference sync get/set")
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
 drivers/dpll/dpll_netlink.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
index bf729cde796a7..5703667593a7c 100644
--- a/drivers/dpll/dpll_netlink.c
+++ b/drivers/dpll/dpll_netlink.c
@@ -567,6 +567,9 @@ dpll_msg_add_pin_ref_sync(struct sk_buff *msg, struct dpll_pin *pin,
 		if (!dpll_pin_available(ref_sync_pin))
 			continue;
 		ref_sync_pin_priv = dpll_pin_on_dpll_priv(dpll, ref_sync_pin);
+		/* Pin may have been unregistered from this dpll already */
+		if (!ref_sync_pin_priv)
+			continue;
 		if (WARN_ON(!ops->ref_sync_get))
 			return -EOPNOTSUPP;
 		ret = ops->ref_sync_get(pin, pin_priv, ref_sync_pin,
-- 
2.53.0

Re: [PATCH net] dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()

Posted by Jiri Pirko 1 week, 5 days ago

Fri, Jul 10, 2026 at 09:36:25PM +0200, ivecera@redhat.com wrote:
>When a dpll_pin is shared across multiple dpll_device instances and
>those devices are being unregistered (e.g. during driver module removal),
>a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync().
>
>This happens under the following conditions:
> - A pin is registered with two or more dpll devices (dpll_A, dpll_B)
> - The pin has ref_sync pairs with other pins
> - During unregistration of dpll_A's pins, a ref_sync partner pin is
>   unregistered first, removing it from dpll_A->pin_refs
> - But since the partner pin is still registered with dpll_B, its
>   dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT
>   run and the partner stays in the pin's ref_sync_pins xarray
> - When the pin itself is then unregistered from dpll_A, the delete
>   notification calls dpll_msg_add_pin_ref_sync() which finds the
>   partner in ref_sync_pins, passes dpll_pin_available() (partner is
>   still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A,
>   partner) returns NULL because partner was already removed from
>   dpll_A->pin_refs
> - The NULL priv pointer is passed to the driver's ref_sync_get
>   callback, which dereferences it
>
> BUG: kernel NULL pointer dereference, address: 0000000000000034
> Oops: Oops: 0000 [#1] SMP NOPTI
> RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x]
> Call Trace:
>  dpll_msg_add_pin_ref_sync+0xb8/0x200
>  dpll_cmd_pin_get_one+0x3b6/0x4b0
>  dpll_pin_event_send+0x72/0x140
>  __dpll_pin_unregister+0x5a/0x2b0
>  dpll_pin_unregister+0x49/0x70
>
>Fix this by skipping ref_sync pins whose priv pointer cannot be resolved
>for the current dpll device.
>
>Fixes: 58256a26bfb3 ("dpll: add reference sync get/set")
>Signed-off-by: Ivan Vecera <ivecera@redhat.com>

Reviewed-by: Jiri Pirko <jiri@nvidia.com>

Re: [PATCH net] dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()

Posted by Vadim Fedorenko 2 weeks, 1 day ago

On 10/07/2026 20:36, Ivan Vecera wrote:
> When a dpll_pin is shared across multiple dpll_device instances and
> those devices are being unregistered (e.g. during driver module removal),
> a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync().
> 
> This happens under the following conditions:
>   - A pin is registered with two or more dpll devices (dpll_A, dpll_B)
>   - The pin has ref_sync pairs with other pins
>   - During unregistration of dpll_A's pins, a ref_sync partner pin is
>     unregistered first, removing it from dpll_A->pin_refs
>   - But since the partner pin is still registered with dpll_B, its
>     dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT
>     run and the partner stays in the pin's ref_sync_pins xarray
>   - When the pin itself is then unregistered from dpll_A, the delete
>     notification calls dpll_msg_add_pin_ref_sync() which finds the
>     partner in ref_sync_pins, passes dpll_pin_available() (partner is
>     still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A,
>     partner) returns NULL because partner was already removed from
>     dpll_A->pin_refs
>   - The NULL priv pointer is passed to the driver's ref_sync_get
>     callback, which dereferences it
> 
>   BUG: kernel NULL pointer dereference, address: 0000000000000034
>   Oops: Oops: 0000 [#1] SMP NOPTI
>   RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x]
>   Call Trace:
>    dpll_msg_add_pin_ref_sync+0xb8/0x200
>    dpll_cmd_pin_get_one+0x3b6/0x4b0
>    dpll_pin_event_send+0x72/0x140
>    __dpll_pin_unregister+0x5a/0x2b0
>    dpll_pin_unregister+0x49/0x70
> 
> Fix this by skipping ref_sync pins whose priv pointer cannot be resolved
> for the current dpll device.
> 
> Fixes: 58256a26bfb3 ("dpll: add reference sync get/set")
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
>   drivers/dpll/dpll_netlink.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
> index bf729cde796a7..5703667593a7c 100644
> --- a/drivers/dpll/dpll_netlink.c
> +++ b/drivers/dpll/dpll_netlink.c
> @@ -567,6 +567,9 @@ dpll_msg_add_pin_ref_sync(struct sk_buff *msg, struct dpll_pin *pin,
>   		if (!dpll_pin_available(ref_sync_pin))
>   			continue;
>   		ref_sync_pin_priv = dpll_pin_on_dpll_priv(dpll, ref_sync_pin);
> +		/* Pin may have been unregistered from this dpll already */
> +		if (!ref_sync_pin_priv)
> +			continue;
>   		if (WARN_ON(!ops->ref_sync_get))
>   			return -EOPNOTSUPP;
>   		ret = ops->ref_sync_get(pin, pin_priv, ref_sync_pin,

well, a bit strange, but if you can hit this issue, we have to fix it.

Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>