raw_release() unregisters raw CAN receive filters via can_rx_unregister(),
but receiver deletion is deferred with call_rcu(). This leaves a window
where raw_rcv() may still be running in an RCU read-side critical section
after raw_release() frees ro->uniq, leading to a use-after-free of the
percpu uniq storage.

Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific
socket destructor. can_rx_unregister() takes an extra reference to the
socket and only drops it from the RCU callback, so freeing uniq from
sk_destruct ensures the percpu area is not released until the relevant
callbacks have drained.

Fixes: 514ac99c64b2 ("can: fix multiple delivery of a single CAN frame for overlapping CAN filters")
Cc: stable@vger.kernel.org # v4.1+
Assisted-by: Bynario AI
Signed-off-by: Samuel Page <sam@bynar.io>

---
  net/can/raw.c | 11 ++++++++++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/net/can/raw.c b/net/can/raw.c
index eee244ffc31e..f042c4316890 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -361,6 +361,14 @@ static int raw_notifier(struct notifier_block *nb, unsigned long msg,
  	return NOTIFY_DONE;
  }
  
+static void raw_sock_destruct(struct sock *sk)
+{
+	struct raw_sock *ro = raw_sk(sk);
+
+	free_percpu(ro->uniq);
+	can_sock_destruct(sk);
+}
+
  static int raw_init(struct sock *sk)
  {
  	struct raw_sock *ro = raw_sk(sk);
@@ -387,6 +395,8 @@ static int raw_init(struct sock *sk)
  	if (unlikely(!ro->uniq))
  		return -ENOMEM;
  
+	sk->sk_destruct = raw_sock_destruct;
+
  	/* set notifier */
  	spin_lock(&raw_notifier_lock);
  	list_add_tail(&ro->notifier, &raw_notifier_list);
@@ -436,7 +446,6 @@ static int raw_release(struct socket *sock)
  	ro->bound = 0;
  	ro->dev = NULL;
  	ro->count = 0;
-	free_percpu(ro->uniq);
  
  	sock_orphan(sk);
  	sock->sk = NULL;
-- 
2.49.0

On 08.04.26 16:30, Sam P wrote:
> raw_release() unregisters raw CAN receive filters via can_rx_unregister(),
> but receiver deletion is deferred with call_rcu(). This leaves a window
> where raw_rcv() may still be running in an RCU read-side critical section
> after raw_release() frees ro->uniq, leading to a use-after-free of the
> percpu uniq storage.
> 
> Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific
> socket destructor. can_rx_unregister() takes an extra reference to the
> socket and only drops it from the RCU callback, so freeing uniq from
> sk_destruct ensures the percpu area is not released until the relevant
> callbacks have drained.
> 
> Fixes: 514ac99c64b2 ("can: fix multiple delivery of a single CAN frame 
> for overlapping CAN filters")
> Cc: stable@vger.kernel.org # v4.1+
> Assisted-by: Bynario AI
> Signed-off-by: Samuel Page <sam@bynar.io>

Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>

> 
> ---
>   net/can/raw.c | 11 ++++++++++-
>   1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/net/can/raw.c b/net/can/raw.c
> index eee244ffc31e..f042c4316890 100644
> --- a/net/can/raw.c
> +++ b/net/can/raw.c
> @@ -361,6 +361,14 @@ static int raw_notifier(struct notifier_block *nb, 
> unsigned long msg,
>       return NOTIFY_DONE;
>   }
> 
> +static void raw_sock_destruct(struct sock *sk)
> +{
> +    struct raw_sock *ro = raw_sk(sk);
> +
> +    free_percpu(ro->uniq);
> +    can_sock_destruct(sk);
> +}
> +
>   static int raw_init(struct sock *sk)
>   {
>       struct raw_sock *ro = raw_sk(sk);
> @@ -387,6 +395,8 @@ static int raw_init(struct sock *sk)
>       if (unlikely(!ro->uniq))
>           return -ENOMEM;
> 
> +    sk->sk_destruct = raw_sock_destruct;
> +
>       /* set notifier */
>       spin_lock(&raw_notifier_lock);
>       list_add_tail(&ro->notifier, &raw_notifier_list);
> @@ -436,7 +446,6 @@ static int raw_release(struct socket *sock)
>       ro->bound = 0;
>       ro->dev = NULL;
>       ro->count = 0;
> -    free_percpu(ro->uniq);
> 
>       sock_orphan(sk);
>       sock->sk = NULL;

Hello Sam,

many thanks for your investigation and for the provided fix.
Excellent work!

Btw. you also suggested a different solution with synchronize_rcu():

diff --git a/net/can/raw.c b/net/can/raw.c
index eee244ffc31e..5bb9a84f2471 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -431,6 +431,13 @@ static int raw_release(struct socket *sock)
      if (ro->count > 1)
          kfree(ro->filter);

+    /*
+     * Wait for any in-flight raw_rcv() calls to finish before freeing
+     * ro->uniq.  can_rx_unregister() scheduled deletion via call_rcu(),
+     * but RCU readers (raw_rcv in softirq) may still be active.
+     */
+    synchronize_rcu();
+
      ro->ifindex = 0;
      ro->bound = 0;
      ro->dev = NULL;


Can you tell why you preferred the destructor solution now?

And if I see it correctly the UAF problem might also show up with the
kfree(ro->filter) statement we can see at the beginning of the above patch.

So either free_percpu(ro->uniq) and kfree(ro->filter) should be handled 
after the finalized synchronize_rcu() process, right?

Many thanks and best regards,
Oliver


On 08.04.26 16:30, Sam P wrote:
> raw_release() unregisters raw CAN receive filters via can_rx_unregister(),
> but receiver deletion is deferred with call_rcu(). This leaves a window
> where raw_rcv() may still be running in an RCU read-side critical section
> after raw_release() frees ro->uniq, leading to a use-after-free of the
> percpu uniq storage.
> 
> Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific
> socket destructor. can_rx_unregister() takes an extra reference to the
> socket and only drops it from the RCU callback, so freeing uniq from
> sk_destruct ensures the percpu area is not released until the relevant
> callbacks have drained.
> 
> Fixes: 514ac99c64b2 ("can: fix multiple delivery of a single CAN frame 
> for overlapping CAN filters")
> Cc: stable@vger.kernel.org # v4.1+
> Assisted-by: Bynario AI
> Signed-off-by: Samuel Page <sam@bynar.io>
> 
> ---
>   net/can/raw.c | 11 ++++++++++-
>   1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/net/can/raw.c b/net/can/raw.c
> index eee244ffc31e..f042c4316890 100644
> --- a/net/can/raw.c
> +++ b/net/can/raw.c
> @@ -361,6 +361,14 @@ static int raw_notifier(struct notifier_block *nb, 
> unsigned long msg,
>       return NOTIFY_DONE;
>   }
> 
> +static void raw_sock_destruct(struct sock *sk)
> +{
> +    struct raw_sock *ro = raw_sk(sk);
> +
> +    free_percpu(ro->uniq);
> +    can_sock_destruct(sk);
> +}
> +
>   static int raw_init(struct sock *sk)
>   {
>       struct raw_sock *ro = raw_sk(sk);
> @@ -387,6 +395,8 @@ static int raw_init(struct sock *sk)
>       if (unlikely(!ro->uniq))
>           return -ENOMEM;
> 
> +    sk->sk_destruct = raw_sock_destruct;
> +
>       /* set notifier */
>       spin_lock(&raw_notifier_lock);
>       list_add_tail(&ro->notifier, &raw_notifier_list);
> @@ -436,7 +446,6 @@ static int raw_release(struct socket *sock)
>       ro->bound = 0;
>       ro->dev = NULL;
>       ro->count = 0;
> -    free_percpu(ro->uniq);
> 
>       sock_orphan(sk);
>       sock->sk = NULL;

On 08/04/2026 17:28, Oliver Hartkopp wrote:
> Hello Sam,
> 
> many thanks for your investigation and for the provided fix.
> Excellent work!
> 
> Btw. you also suggested a different solution with synchronize_rcu():
> 
> diff --git a/net/can/raw.c b/net/can/raw.c
> index eee244ffc31e..5bb9a84f2471 100644
> --- a/net/can/raw.c
> +++ b/net/can/raw.c
> @@ -431,6 +431,13 @@ static int raw_release(struct socket *sock)
>       if (ro->count > 1)
>           kfree(ro->filter);
> 
> +    /*
> +     * Wait for any in-flight raw_rcv() calls to finish before freeing
> +     * ro->uniq.  can_rx_unregister() scheduled deletion via call_rcu(),
> +     * but RCU readers (raw_rcv in softirq) may still be active.
> +     */
> +    synchronize_rcu();
> +
>       ro->ifindex = 0;
>       ro->bound = 0;
>       ro->dev = NULL;
> 
> 
> Can you tell why you preferred the destructor solution now?

Thank you :) I preferred the destructor solution as it seemed to match the socket lifetime model better and I wasn't sure if the blocking sync in the raw_release() was too heavy-handed for this specific issue, given raw_release() already holds rtnl_lock() and lock_sock(sk). That said, I'm happy to defer to your experience if the sync fix is better suited, I have tested both of them.

> And if I see it correctly the UAF problem might also show up with the
> kfree(ro->filter) statement we can see at the beginning of the above patch.
> 
> So either free_percpu(ro->uniq) and kfree(ro->filter) should be handled after the finalized synchronize_rcu() process, right?

ro->filter isn't accessed in the racey raw_rcv() path as far as I can tell, and I don't *think* there are other racey paths but it wouldn't hurt to handle it just in-case. I think this would be simple with the synchronize_rcu() patch, as you mentioned, but I'm not sure with the destructor.

Kind Regards,
Sam

On 08.04.26 19:22, Sam P wrote:
> On 08/04/2026 17:28, Oliver Hartkopp wrote:

>>
>> Can you tell why you preferred the destructor solution now?
> 
> Thank you :) I preferred the destructor solution as it seemed to match 
> the socket lifetime model better and I wasn't sure if the blocking sync 
> in the raw_release() was too heavy-handed for this specific issue, given 
> raw_release() already holds rtnl_lock() and lock_sock(sk). That said, 
> I'm happy to defer to your experience if the sync fix is better suited, 
> I have tested both of them.

Thanks. I think rtnl_lock() really might create a performance impact to 
other networking code when syncronize_rcu() waits for its grace period.

>> And if I see it correctly the UAF problem might also show up with the
>> kfree(ro->filter) statement we can see at the beginning of the above 
>> patch.
>>
>> So either free_percpu(ro->uniq) and kfree(ro->filter) should be 
>> handled after the finalized synchronize_rcu() process, right?
> 
> ro->filter isn't accessed in the racey raw_rcv() path as far as I can 
> tell, and I don't *think* there are other racey paths but it wouldn't 
> hurt to handle it just in-case. I think this would be simple with the 
> synchronize_rcu() patch, as you mentioned, but I'm not sure with the 
> destructor.

ro->filter contains all the CAN_RAW specific CAN ID filters and is 
allocated if more than the single default filter is required.

It is last used in the raw_disable_allfilters() above.

So after the good discussion I tend to your original approach with the 
destructor ;-)

Will add my Acked-by: to the original posted patch.

Many thanks,
Oliver