* [PATCH can-next v5 0/5] can: protect the receive lists with a per-device lock
@ 2026-10-21 8:02 Oliver Hartkopp
0 siblings, 0 replies; 7+ messages in thread
From: Oliver Hartkopp @ 2026-10-21 8:02 UTC (permalink / raw)
To: linux-can; +Cc: Oliver Hartkopp
This series fixes a use-after-free in CAN_ISOTP and CAN_BCM that can be
triggered when a CAN device is moved to another network namespace while
a socket bound to this device is released [1].
The code of patches 1-4 is unchanged. Only the commit message of patch 4
has been updated after the Sashiko review of v4 to describe the actual
NULL pointer dereference in can_rx_unregister() and the CAN_ISOTP path
that reaches it.
The series is based on linux-can-next/testing, which also contains
"can: raw: remove redundant NULL check before netdev_hold()" from [2].
The idea behind patch 5:
The receive lists of a CAN device are located in the device's
can_ml_priv and travel with the device when it is moved to another
network namespace. But they are protected by the per-netns
rcvlists_lock, so the lock that protects a device's lists depends on
the namespace the caller passes to can_rx_register() and
can_rx_unregister(). can_rx_unregister() silently returns when this
namespace does not match dev_net(dev) anymore.
isotp_release() and bcm_release() leave the netdev notifier list before
they can serialize against the notifier. When the device changes its
namespace in this window, their filters are not removed and the
remaining receivers point to the freed socket or bcm op.
Taking RTNL in these release paths is no option, as CAN_RAW already
holds RTNL while adding and removing up to CAN_RAW_FILTER_MAX filters
per socket, which unprivileged users can trigger repeatedly.
Instead, patch 5 protects the receive lists where they are located: A
spinlock in struct can_dev_rcv_lists protects the lists of a CAN device
(initialized in can_set_ml_priv()) or the 'any' CAN device lists of a
namespace (initialized in can_pernet_init()). can_rx_unregister() then
finds the subscription independently of the current namespace of the
device, which is kept accessible by the tracked device references the
protocols already hold. The per-netns rcvlists_lock only protects the
receive list statistics, for which CAN_RAW, CAN_BCM and CAN_ISOTP pass
the namespace that has been used for can_rx_register().
As a consequence, CAN_RAW and CAN_ISOTP do not need RTNL in bind(),
setsockopt() and release() anymore. bind() is serialized against
NETDEV_UNREGISTER by publishing the device inside the RCU section of
its lookup, as unlist_netdevice() and synchronize_net() precede
NETDEV_UNREGISTER both on unregistration and on a namespace change.
The notifiers recheck the binding under lock_sock(). As RTNL does not
keep NETDEV_DOWN out of bind() anymore, bind() checks IFF_UP after
publishing the bound device, with an smp_mb() pair against the
notifiers, so a down transition during bind() is still reported with
ENETDOWN.
Changes in v5 (details in patch 5):
- report ENETDOWN for a down transition during bind() again
- comment and kernel-doc updates
- patch 4: commit message describes the actual crash path
(all from the Sashiko review of v4)
[1] https://lore.kernel.org/linux-can/CEA6A38A-2646-4ADA-95B4-CBAE2F301A8E@doyensec.com/
[2] https://lore.kernel.org/linux-can/20261018164417.1540449-1-mkl@pengutronix.de/
Previous versions of patch 5:
v4: https://lore.kernel.org/linux-can/20261019152741.54854-6-socketcan@hartkopp.net/
v3: https://lore.kernel.org/linux-can/20261019074244.50391-5-socketcan@hartkopp.net/
v2: https://lore.kernel.org/linux-can/20261018180739.689750-1-socketcan@hartkopp.net/
v1: https://lore.kernel.org/linux-can/20261017201935.399233-1-socketcan@hartkopp.net/
Oliver Hartkopp (4):
can: proc: skip stats calculation after reset in can_stat_update()
can: proc: remove pointers from CAN specific proc output
can: replace ARPHRD_CAN type checks with can_get_ml_priv()
can: protect the receive lists with a per-device lock
Runyu Xiao (1):
can: proc: reset pkg_stats atomics individually
Documentation/networking/can.rst | 16 +--
include/linux/can/can-ml.h | 3 +
include/linux/can/core.h | 2 +-
include/net/netns/can.h | 2 +-
net/can/af_can.c | 60 +++++++-----
net/can/af_can.h | 2 +-
net/can/bcm.c | 64 +++++-------
net/can/gw.c | 9 +-
net/can/isotp.c | 57 ++++++++---
net/can/j1939/main.c | 2 +-
net/can/proc.c | 95 +++++++++++-------
net/can/raw.c | 163 ++++++++++++++++++++-----------
12 files changed, 284 insertions(+), 191 deletions(-)
--
2.43.0
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH can-next v5 0/5] can: protect the receive lists with a per-device lock
@ 2026-10-20 20:32 Oliver Hartkopp
2026-10-21 7:36 ` Marc Kleine-Budde
0 siblings, 1 reply; 7+ messages in thread
From: Oliver Hartkopp @ 2026-10-20 20:32 UTC (permalink / raw)
To: linux-can; +Cc: Oliver Hartkopp
This series fixes a use-after-free in CAN_ISOTP and CAN_BCM that can be
triggered when a CAN device is moved to another network namespace while
a socket bound to this device is released [1].
Only patch 5 is new. Patches 1-4 are already applied to the testing
branch of linux-can-next, and patches 1, 3 and 4 are on their way to
net-next with the linux-can-next pull request [2]. They are included
only to provide a sequence on which the sashiko bot is able to build and
review patch 5. Please do not apply patches 1-4 from this series.
The code of patches 1-4 is unchanged. Only the commit message of patch 4
has been updated after the Sashiko review of v4 to describe the actual
NULL pointer dereference in can_rx_unregister() and the CAN_ISOTP path
that reaches it.
The series is based on linux-can-next/testing, which also contains
"can: raw: remove redundant NULL check before netdev_hold()" from [2].
The idea behind patch 5:
The receive lists of a CAN device are located in the device's
can_ml_priv and travel with the device when it is moved to another
network namespace. But they are protected by the per-netns
rcvlists_lock, so the lock that protects a device's lists depends on
the namespace the caller passes to can_rx_register() and
can_rx_unregister(). can_rx_unregister() silently returns when this
namespace does not match dev_net(dev) anymore.
isotp_release() and bcm_release() leave the netdev notifier list before
they can serialize against the notifier. When the device changes its
namespace in this window, their filters are not removed and the
remaining receivers point to the freed socket or bcm op.
Taking RTNL in these release paths is no option, as CAN_RAW already
holds RTNL while adding and removing up to CAN_RAW_FILTER_MAX filters
per socket, which unprivileged users can trigger repeatedly.
Instead, patch 5 protects the receive lists where they are located: A
spinlock in struct can_dev_rcv_lists protects the lists of a CAN device
(initialized in can_set_ml_priv()) or the 'any' CAN device lists of a
namespace (initialized in can_pernet_init()). can_rx_unregister() then
finds the subscription independently of the current namespace of the
device, which is kept accessible by the tracked device references the
protocols already hold. The per-netns rcvlists_lock only protects the
receive list statistics, for which CAN_RAW, CAN_BCM and CAN_ISOTP pass
the namespace that has been used for can_rx_register().
As a consequence, CAN_RAW and CAN_ISOTP do not need RTNL in bind(),
setsockopt() and release() anymore. bind() is serialized against
NETDEV_UNREGISTER by publishing the device inside the RCU section of
its lookup, as unlist_netdevice() and synchronize_net() precede
NETDEV_UNREGISTER both on unregistration and on a namespace change.
The notifiers recheck the binding under lock_sock(). As RTNL does not
keep NETDEV_DOWN out of bind() anymore, bind() checks IFF_UP after
publishing the bound device, with an smp_mb() pair against the
notifiers, so a down transition during bind() is still reported with
ENETDOWN.
Changes in v5 (details in patch 5):
- report ENETDOWN for a down transition during bind() again
- comment and kernel-doc updates
- patch 4: commit message describes the actual crash path
(all from the Sashiko review of v4)
[1] https://lore.kernel.org/linux-can/CEA6A38A-2646-4ADA-95B4-CBAE2F301A8E@doyensec.com/
[2] https://lore.kernel.org/linux-can/20261018164417.1540449-1-mkl@pengutronix.de/
Previous versions of patch 5:
v4: https://lore.kernel.org/linux-can/20261019152741.54854-6-socketcan@hartkopp.net/
v3: https://lore.kernel.org/linux-can/20261019074244.50391-5-socketcan@hartkopp.net/
v2: https://lore.kernel.org/linux-can/20261018180739.689750-1-socketcan@hartkopp.net/
v1: https://lore.kernel.org/linux-can/20261017201935.399233-1-socketcan@hartkopp.net/
Oliver Hartkopp (4):
can: proc: skip stats calculation after reset in can_stat_update()
can: proc: remove pointers from CAN specific proc output
can: replace ARPHRD_CAN type checks with can_get_ml_priv()
can: protect the receive lists with a per-device lock
Runyu Xiao (1):
can: proc: reset pkg_stats atomics individually
Documentation/networking/can.rst | 16 +--
include/linux/can/can-ml.h | 3 +
include/linux/can/core.h | 2 +-
include/net/netns/can.h | 2 +-
net/can/af_can.c | 60 +++++++-----
net/can/af_can.h | 2 +-
net/can/bcm.c | 64 +++++-------
net/can/gw.c | 9 +-
net/can/isotp.c | 57 ++++++++---
net/can/j1939/main.c | 2 +-
net/can/proc.c | 95 +++++++++++-------
net/can/raw.c | 163 ++++++++++++++++++++-----------
12 files changed, 284 insertions(+), 191 deletions(-)
--
2.43.0
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH can-next v5 0/5] can: protect the receive lists with a per-device lock
2026-10-20 20:32 Oliver Hartkopp
@ 2026-10-21 7:36 ` Marc Kleine-Budde
2026-10-21 7:50 ` Oliver Hartkopp
0 siblings, 1 reply; 7+ messages in thread
From: Marc Kleine-Budde @ 2026-10-21 7:36 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
On 20.10.2026 22:32:52, Oliver Hartkopp wrote:
> This series fixes a use-after-free in CAN_ISOTP and CAN_BCM that can be
> triggered when a CAN device is moved to another network namespace while
> a socket bound to this device is released [1].
>
> Only patch 5 is new. Patches 1-4 are already applied to the testing
> branch of linux-can-next, and patches 1, 3 and 4 are on their way to
> net-next with the linux-can-next pull request [2]. They are included
> only to provide a sequence on which the sashiko bot is able to build and
> review patch 5. Please do not apply patches 1-4 from this series.
Can you adjust the patch description?
Marc
pw-bot: cr
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH can-next v5 0/5] can: protect the receive lists with a per-device lock
2026-10-21 7:36 ` Marc Kleine-Budde
@ 2026-10-21 7:50 ` Oliver Hartkopp
2026-10-21 7:59 ` Marc Kleine-Budde
0 siblings, 1 reply; 7+ messages in thread
From: Oliver Hartkopp @ 2026-10-21 7:50 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: linux-can@vger.kernel.org
On 21.10.26 09:36, Marc Kleine-Budde wrote:
> On 20.10.2026 22:32:52, Oliver Hartkopp wrote:
>> This series fixes a use-after-free in CAN_ISOTP and CAN_BCM that can be
>> triggered when a CAN device is moved to another network namespace while
>> a socket bound to this device is released [1].
>>
>> Only patch 5 is new. Patches 1-4 are already applied to the testing
>> branch of linux-can-next, and patches 1, 3 and 4 are on their way to
>> net-next with the linux-can-next pull request [2]. They are included
>> only to provide a sequence on which the sashiko bot is able to build and
>> review patch 5. Please do not apply patches 1-4 from this series.
>
> Can you adjust the patch description?
>
> Marc
>
> pw-bot: cr
>
The second section in the cover-letter (which does not land in the
kernel or anywhere else) became obsolete.
Do you really want a v6 respin for that nitpick?
Best regards,
Oliver
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH can-next v5 0/5] can: protect the receive lists with a per-device lock
2026-10-21 7:50 ` Oliver Hartkopp
@ 2026-10-21 7:59 ` Marc Kleine-Budde
2026-10-21 8:04 ` Oliver Hartkopp
0 siblings, 1 reply; 7+ messages in thread
From: Marc Kleine-Budde @ 2026-10-21 7:59 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]
On 21.10.2026 09:50:15, Oliver Hartkopp wrote:
>
>
> On 21.10.26 09:36, Marc Kleine-Budde wrote:
> > On 20.10.2026 22:32:52, Oliver Hartkopp wrote:
> > > This series fixes a use-after-free in CAN_ISOTP and CAN_BCM that can be
> > > triggered when a CAN device is moved to another network namespace while
> > > a socket bound to this device is released [1].
> > >
> > > Only patch 5 is new. Patches 1-4 are already applied to the testing
> > > branch of linux-can-next, and patches 1, 3 and 4 are on their way to
> > > net-next with the linux-can-next pull request [2]. They are included
> > > only to provide a sequence on which the sashiko bot is able to build and
> > > review patch 5. Please do not apply patches 1-4 from this series.
> >
> > Can you adjust the patch description?
> >
> > Marc
> >
> > pw-bot: cr
> >
>
> The second section in the cover-letter (which does not land in the kernel or
> anywhere else) became obsolete.
>
> Do you really want a v6 respin for that nitpick?
You can add an updated cover letter for this series as a reply here.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH can-next v5 0/5] can: protect the receive lists with a per-device lock
2026-10-21 7:59 ` Marc Kleine-Budde
@ 2026-10-21 8:04 ` Oliver Hartkopp
2026-10-21 8:57 ` Marc Kleine-Budde
0 siblings, 1 reply; 7+ messages in thread
From: Oliver Hartkopp @ 2026-10-21 8:04 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: linux-can@vger.kernel.org
On 21.10.26 09:59, Marc Kleine-Budde wrote:
> On 21.10.2026 09:50:15, Oliver Hartkopp wrote:
>>
>>
>> On 21.10.26 09:36, Marc Kleine-Budde wrote:
>>> On 20.10.2026 22:32:52, Oliver Hartkopp wrote:
>>>> This series fixes a use-after-free in CAN_ISOTP and CAN_BCM that can be
>>>> triggered when a CAN device is moved to another network namespace while
>>>> a socket bound to this device is released [1].
>>>>
>>>> Only patch 5 is new. Patches 1-4 are already applied to the testing
>>>> branch of linux-can-next, and patches 1, 3 and 4 are on their way to
>>>> net-next with the linux-can-next pull request [2]. They are included
>>>> only to provide a sequence on which the sashiko bot is able to build and
>>>> review patch 5. Please do not apply patches 1-4 from this series.
>>>
>>> Can you adjust the patch description?
>>>
>>> Marc
>>>
>>> pw-bot: cr
>>>
>>
>> The second section in the cover-letter (which does not land in the kernel or
>> anywhere else) became obsolete.
>>
>> Do you really want a v6 respin for that nitpick?
>
> You can add an updated cover letter for this series as a reply here.
There it is:
https://lore.kernel.org/linux-can/20261021080231.16408-1-socketcan@hartkopp.net/
Many thanks,
Oliver
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-10-21 8:57 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-21 8:02 [PATCH can-next v5 0/5] can: protect the receive lists with a per-device lock Oliver Hartkopp
-- strict thread matches above, loose matches on Subject: below --
2026-10-20 20:32 Oliver Hartkopp
2026-10-21 7:36 ` Marc Kleine-Budde
2026-10-21 7:50 ` Oliver Hartkopp
2026-10-21 7:59 ` Marc Kleine-Budde
2026-10-21 8:04 ` Oliver Hartkopp
2026-10-21 8:57 ` Marc Kleine-Budde
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.